CollegePAY is a simple page that can be utilized on any website seeking to offer visitors the facility to pay for fees and services by using their bank issued cards or other payment tokens. It is designed for schools and various institutions who have little experience in server side scripting, or who use shared web servers that do not offer secure database services.

With CollegePAY, your customers are redirected to Interswitch's WebPAY secure page to enter their card details, thereby removing the need for you to maintain highly secure encrypted databases, or obtain digital certificates which means an Institution does not need to store sensitive customer information.

  • Easy to set up: CollegePAY Payment Page is easily integrated with most of the major Content management systems.
  • Simple Integration: An institution's website can be ready to accept payment with just a few lines of code.
  • Complete security: transaction security is enabled as CollegePay is certified under the PCI DSS (Payment Card Industry Data Security) Standard. With this, you dont need to worry about cardholder security as they do not process the card data.

Payment page.png?zoom=1

WebPAY Secure Payment Page Overview

WebPAY's main page optionally carries the merchant's logo and a description of the goods the customer is paying for. Once the customer has selected their payment method and confirmed they wish to complete the payment, WebPAY requests authorization from the customer's bank. After payment has been authorization by the users bank, WebPAY redirects the customer back to a page on the institution's website.

The merchant/institution's return page is sent information which can be accessed using standard web technology.

Webpay payment page test card

[Payment page options.png?zoom=1](

Test Payment Cards

As part of the integration, find below test payment card details (PAN, PIN, Expiry Date, CVV2) to help you test out CollegePay. You cant use real credit/debit cards on the Test environment and vice versa*. Note also that on the test environment no real debit or credit occurs to any bank account.

Webpay payment page test card](

Type of Card Card PAN Expiry Date (Full) Expiry Date (Short) PIN CVV2
Successful Transactions Card 6280511000000095 December 2026 12/26 0000 123
VISA Test Card 4000000000000622 January 2020 01/20 N/A 535
Insufficient Funds Card 5061030000000000027 January 2022 01/22 1234 123
No Card Record Card 5061030000000000043 January 2022 01/22 1234 123
Exceeds Withdrawal Limit Card 5061030000000000068 January 2022 01/22 1234 123
Incorrect PIN Card 5061030000000000035 January 2022 01/22 0000 123
Refer to Card Issuer (sometimes masked as Transaction error on WebPAY) 5061030000000000050 January 2022 01/22 1234 123

Help Line

If you require any assistance/clarification concerning the details contained in this documentation, please feel free to contact us at and +234-1-9065000.

Webpay CMS Plugins

WordPress Plugin

OpenCart Plugin


Select below the version of WebPAY you would like to Demo


CollegePAY is a flexible and secure internet payment gateway that conforms to Internet standards and common integration methods. See major features below:

  • Integration with 2-factor authentication services.
  • Standards compliant web page (HTTPS, CSS 2 and JavaScript)
  • Mobile friendly page
  • URL redirection to merchant website return page at the conclusion of an authorization (with POST data)



Payment leg


Requery leg

Step 1

A HTTP POST request is made with certain transaction parameters to the Interswitch payment gateway service URL ( This is known as the beginning of the payment leg.

Step 2

A response is sent from the payment gateway. The response is sent to your site_redirect_url parameter specified in your POST request in Step 1 above. This ends the payment leg.

Step 3

The merchant's website initiates a HTTP GET request to the payment gateway requesting the status of the concluded Payment transaction (i.e., Steps 1 & 2 above). This is the beginning of the getTransaction leg.

Step 4

A response is sent from the payment gateway containing the complete status of the transaction.

Transaction Payment Leg

Processing & Submission of Payment Data (PAYMENT LEG)

Integrating CollegePAY with an existing website is extremely easy and can be achieved with a few simple steps. The only requirement is to create a HTML form in the referring web page that contains a few mandatory fields. In addition, you will need to decide if Payment is to be SPLIT between multiple accounts, or all funds are to be domiciled in one account only. Bear in mind the instruction to SPLIT or not is sent from you to the WebPAY Service to execute.

Form Creation

  • Create a form in the location that the  button should appear
  • Set the form's action to
  • Set the form's HTTP method to POST
  • Create hidden fields with details shown the table below. Note that only 7 fields are mandatory .i.e.

    • product_id,
    • amount,
    • currency,
    • site_redirect_url,
    • *txn_ref, hash *and
    • pay_item_id
  • Create a submit button in the form.

<form name="form1"  action=""  method="POST">
<input name="product_id"  type="hidden"  value="6207" />
<input name="pay_item_id"  type="hidden"  value="103" />
<input name="amount"  type="hidden"  value="50000" />
<input name="currency"  type="hidden"  value="566" />
<input name="site_redirect_url"  type="hidden"  value="" />
<input name="txn_ref" type="hidden" value="AB-12385_TT" />
<input name="cust_id" type="hidden" value="AD99" />
<input name="hash" type="hidden" value="B48FEE432779ED2B2532677AD49C45EC03541B4555D6F439C1174B8F3D7A83E4B9B40223538E1EB5D834A7C1D04A32E984A41DBE2D8565B129B013BE1D1456DF"/>
<input type="submit" value="PAY  NOW"></input>

HTTP POST Form Fields

Field Field Description Requirement Expected Values Format
amount Mandatory Transaction Amount in Kobo denomination\
(Eg 200000 for ₦2,000) Value decided by Merchant Numeric
currency Mandatory Currency of the transaction 566 (Naira) Numeric
cust_id Mandatory Unique Identifier for customer on Merchant's own website Merchant Provide Alphanumeric
hash Mandatory A Hashed value of selected combined parameters (See here for more details) Value decided by Merchant Alphanumeric
txn_ref Mandatory Transaction Reference or identifier. Each and every transaction must have an identifier or reference. No 2 transactions must share the same reference (duplicates not allowed).\
This Reference Number must be generated by your web site/portal and a unique value must be sent for each transaction (max 15 characters) Value decided by Merchant Alphanumeric
pay_item_id Mandatory Merchant Payment Item Identifier on WebPAY Provided by Interswitch Numeric
product_id Mandatory Merchant Product Identifier on WebPAY. Provided by Interswitch Numeric
site_redirect_url Mandatory URL of the page on your web site/portal user is to be redirected to after payment. You may want to add encrypted authentication information to allow a user renter the web site/portal transparently without being challenged Value decided by Merchant Alphanumeric
cust_id_desc Optional Customer Identification Number description. A descriptive name/label for Customer\
Identification Number above. Value decided by Merchant Alphanumeric
cust_name Optional Name of customer as specified on Merchant's website Value decided by Merchant Alphanumeric
Cust_name_desc Optional Customer Name Description. A descriptive name/label for Customer Name above. Value decided by Merchant Alphanumeric
local_date_time Optional Local Transaction Date Time in format\
DD--MMM--YY HH:MM:SS Value decided by Merchant DateTime
site_name Optional Internet site name of the web site/ portal from which http post is coming from (E.g.\
Note: This internet site name will be authenticated. Value decided by Merchant Alphanumeric
pay_item_name Optional Internet site name of the web site/ portal from which http post is coming from (E.g.\
Note: This internet site name will be authenticated. Provided by Interswitch Numeric
payment_params Optional To activate miscellaneous payment parameters\
(For more details on sending SPLIT click here) Value decided by Merchant Alphanumeric
xml_data Optional Any other data that needs to be sent will be packaged in XML Format and put in this field.\

Bank details of payments that are to be SPLI are specified here\ (For more details on sending SPLIT click here) | Value decided by Merchant | XML |

Request Hash Calculation

The following fields are to be combined and hashed using SHA512 algorithm and this private hash key assigned to the hash POST field:-

  • txn_ref
  • product_id
  • pay_item_id
  • amount
  • site_redirect_url
  • MacKey

Payment hash

where '+' represents string concatenation of values (i.e, "a" + "b" = "ab").

Please note the order of the parameters below:

Mac Key:- This is a 128 character alphanumeric string that is used to calculate the hash. It is usually provided when the merchant is about to Go Live (i.e start accepting real payments). For DEMO transactions, the following value should be used:- D3D1D05AFE42AD50818167EAC73C109168A0F108F32645C8B59E897FA930DA44F9230910DAC9E20641823799A107A02068F7BC0F4CC41D2952E249552255710F Please be wary of extra characters and spaces when working with the MAC Key and hash computation.

Hash Computation Example

For example for a transaction with the following field values --

1) txn_ref -- MYC_060616_31 2) product_id -- 6207 3) pay_item_id -- 103 4) amount -- 125000 (i.e ₦1,250) 5) site_redirect_url -- 6) MacKey -- CEF793CBBE838AA0CBB29B74D571113B4EA6586D3BA77E7C FA0B95E278364EFC4526ED7BD255A366CDDE11F1F607F0F844B09D93B16F7CFE87563B2272007AB3

String to be hashed = MYC_060616_316207103125000

After computing value...

Hash =BA2D7AB317C840970C63D1B0B9517ED73FEC0A399058D0F3BB9EFC7CB9A9F69025C704D944F0040C8EA344B5DA5BB7C74385380F7AC14E30F097AAFA92D2FBDE

A good resource where you can check the hash you;re generating can be found at the link below-

SHA 512 Generator


Sample Response & Fields

Payment Response

The following are the parameters returned by WebPAY for real time transactions.

Field Field Description Expected Values
apprAmt Will always have a value of 0 0
cardNum Will always have a value of 0 0
payRef A reference number that uniquely identifies all transactions that goes through the gateway variable
retRef Reference number from the switch's interconnecting with the banking application variable
txnref The transaction Reference initially generated & sent by the merchant site will be sent back with this variable variable

Payment response page

Successful Transaction Response|WEB|WEBP|20-10-2015|167377&retRef=000000106903&cardNum=0&apprAmt=0&url=http%3a%2f%2flocalhost%2fwebpstaging%2ftpay.php

Failed Transaction Response

Please note, for a failed transaction some response parameters will be empty

The POST back sent from Interswitch can be viewed using Firefox browser as below:-

Firefox redirect1.png?zoom=1

Firefox redirect2.png?zoom=1Firefox redirect3.png?zoom=1

Payment with SPLIT Instruction XML

payment_params For miscellaneous payment parameters variable alphanumeric
xml_data Any other data that needs to be sent will be packaged as xml and put in this field variable XML

'xml_data' Format

<item_details detail_ref="12345"  college="CollegeOfMedicine"  department="Pharmacology"  faculty="MrNaijaD_Class2007">
<item_detail item_id="1"  item_name="Butter"  item_amt="5000"  bank_id="120"  acct_num="1284736289" />
<item_detail item_id="2"  item_name="Juice"  item_amt="12000"  bank_id="16"  acct_num="1277731890" />  </item_details>

The addition of the item_amt in the split data must be the equal to the amount--transaction fee. Hence (*item_amt_1* + item_amt_2 + ...item_amt_X) = (Amount -- TransactionFee). This is to say, that you would like to split a specified amount after the transaction fee has been deducted.
For instance if, Split Item 1 = N500 (destined for a  UBA account -- 9876543210), Split Item 2 = N2,000 (destined for a  GTBank account -- 1234567890), Transaction Fee = N300 (Interswitch Fee to be deducted from total amount before settlement). The above scenario can be represented in XML like below:-

``` html
<input name="amount"  type="hidden"  value="280000"/>
<item_detail item_id="1"  item_name="Butter"  item_amt="50000"  bank_id="7"  acct_num="9876543210"  />
<item_detail item_id="2"  item_name="Juice"  item_amt="200000"bank_id="10"  acct_num="1234567890"  />

Sample Request

<form name="form1"  action=""  method="post">
<input name="product_id"  type="hidden"  value="6207" />
<input name="amount"  type="hidden"  value="175900" />
<input name="currency"  type="hidden"  value="566" />
<input name="site_redirect_url"  type="hidden"  value="">
<input name="site_name"  type="hidden"  value="" />
<input name="cust_id"  type="hidden"  value="a" />
<input name="cust_id_desc"  type="hidden"  value="Value Name" />
<input name="cust_name"  type="hidden"  value="Name <B>Surname</B>" />
<input name="cust_name_desc"  type="hidden"  value="Full name" />
<input name="txn_ref"  type="hidden"  value="AB-12345-TD" />
<input name="pay_item_id"  type="hidden"  value="101" />
<input name="pay_item_name"  type="hidden"  value="Name of Fees/Payment" />
<input name="local_date_time"  type="hidden"  value="" />
<input name="hash"  type="hidden"  value="402D39A072B15B557D0E04E74D6F896EAA98EDFF5B81726C52F6A73C6CC729075C526CCF56EB1ADA1E 336BFA297D2288A069385BD4ED210F381B5F61135BBF0D " />
<input name="payment_params"  type="hidden"  value="college_split" />  
<input name="xml_data"  type="hidden"  value=""/>
<item_details detail_ref="AB-12345-TD" college="College_Of_Medicine" department="PharamacyDept" faculty="MrNaijaD_Class2007">  
<item_detail item_id="1" item_name="Butter" item_amt="55500" bank_id="7" acct_num="9876543210" />  
<item_detail item_id="2" item_name="Juice" item_amt="11100"bank_id="10" acct_num="1234567890" />  


Please note, you will be settled whatever customer was debited less the respective transaction fee. In order to pass this transaction fee to the customer, you can use the following method:-

For transaction fee N300, do the following,\ Let's say the Merchant has an item worth N4,500.\ Amount to be Sent to WebPAY (Y) = 4500 + 300 = 4800\ Fee = 300.\ Amount Settled to Merchant = Y -- Fee\ = 4800 -- 300 = 4500

Transaction Confirmation Leg

Transaction Status Confirmation (GET TRANSACTION LEG)

The purpose of Transaction Status Confirmation is to get the status of the just concluded transaction from CollegePAY Service. This is achieved by means of a HTTP GET request to a service URL.

Getting Transaction Status by Querying the WebService 

This service URL can be used to get the status of a transaction. Below are the HTTP request method and parameters to be used.




Request Parameters

Request Body Parameter Description Format
productid Merchant Product Identifier on WebPAY. Same used in Payment leg Numeric
amount Original amount sent in the transaction, in lower denomination

i.e kobo value. Same value sent in 2.4 above | Numeric | | transactionreference | Original transaction reference sent in the original request  (transaction reference you generated for this | Alphanumeric |

Security Parameters

Request Body Parameter Description Format
hash SHA512 hash of productid, transactionreference and your MAC key . same way you computed your hash in 2.3 above but different parameters this time . This should be sent in the header of the request as Hash

Request Submission

The amount, transaction reference and product id are sent in a HTTP GET request to the service URL with the calculated hash in the header of the request.

$parameters  =  array(
$ponmo  =  http_build_query($parameters)  .  "\n";
$url  =  urlencode(" "  .  $ponmo);  // json
//note the variables appended to the url as get values for these parameters
$headers  =  array(
"GET /HTTP/1.1",
"User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2008070208 Firefox/3.0.1",
"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"Accept-Language: en-us,en;q=0.5",
"Keep-Alive: 300",      
"Connection: keep-alive",
"Hash: "  .  $thash
$ch  =  curl_init();
curl_setopt($ch,  CURLOPT_URL,  $url);
curl_setopt($ch,  CURLOPT_RETURNTRANSFER,  1);
curl_setopt($ch,  CURLOPT_TIMEOUT,  60);
curl_setopt($ch,  CURLOPT_HTTPHEADER,  $headers);
curl_setopt($ch,  CURLOPT_SSL_VERIFYPEER,  false);
curl_setopt($ch,  CURLOPT_SSL_VERIFYHOST,  2);
curl_setopt($ch,  CURLOPT_POST,  false  );


Headers:- Connection: Keep-Alive Host: Hash:2F398AF4D166F7F80225C127F47BDEEB8A4509DCD420F3E04197E7ADA3B29ACD34A11FD966F6F26E741108A86A4BB89D9357BD71F54093599FEB415F8CAC9C76

Find below a sample POSTMan screen grab showing request and response structure below: Resposne webpay hd2 1Resposne webpay hd1 1

Hash Computation

After a concluded PAY transaction and the above parameters were sent to your servers as response. Using the above parameters:-

  • productid (product id as returned by WebPAY)
  • txn_ref (transaction reference as returned by WebPAY)
  • MAC Key (MAC Key used for WebPAY)

Requery hash

where '+' represents string concatenation of values (i.e., "a" + "b" = "ab").

Hash Computation Example

For example for a transaction with the following field values -- 1) txn_ref -- MYC_060616_31 2) product_id -- 6207 3) MacKey -- CEF793CBBE838AA0CBB29B74D571113 B4EA6586D3BA77E7CFA0B95E278364EFC4526ED7BD255A366CDDE11F1F607F0F844B09D93B16F7CFE87563B2272007AB3 String to be hashed = 6207MYC_060616_31CEF793CBBE838AA0CBB29B74D571113B4EA6586D3BA77E7CFA0B9 5E278364EFC4526ED7BD255A366CDDE11F1F607F0F844B09D93B16F7CFE87563B2272007AB3

After computing value

Hash = 511F7BBA87B15BD727F4BC20EE071DD86E6DF71D427A749BEEBA4C1A8808C2D3F82C14DCE1DB9D757E5F592DC9D7A4C20CDAC14CC70784EA42F08DB5B3FB3687

A good resource where you can check the hash you;re generating can be found at the link below-

SHA 512 Generator

Collegepayhash 1

Server Response

Server Response

Various parameters are returned as response after a GET request by CollegePAY. Kindly take note of the following key parameters:-

Parameter Field Description Expected Values
ResponseCode Alphanumeric Code indicating the status of the transaction. Refer to the Response Codes for a list of possible responses alphanumeric
ResponseDescription Brief description of result text
Amount Approved amount numeric
MerchantReference The transaction reference alphanumeric
TransactionDate Date and time transaction took place datetime
    "Amount":  120000,
    "CardNumber":  "0095",
    "MerchantReference":  "1485998442-70",
    "PaymentReference":  "FBN|WEB|WDM|2-02-2017|278803",
    "RetrievalReferenceNumber":  "000517627463",
    "LeadBankCbnCode":  null,
    "LeadBankName":  null,
    "SplitAccounts":  [],
    "TransactionDate":  "2017-02-02T02:21:00.893",
    "ResponseCode":  "00",
    "ResponseDescription":  "Approved Successful"
    "Amount":  0,
    "CardNumber":  null,
    "MerchantReference":  "",
    "PaymentReference":  null,
    "RetrievalReferenceNumber":  null,
    "LeadBankCbnCode":  null,
    "LeadBankName":  null,
    "SplitAccounts":  [],
    "TransactionDate":  "0001-01-01T00:00:00",
    "ResponseCode":  "56",
    "ResponseDescription":  "No Card Record"

Transaction Error


    "Amount":  0,
    "CardNumber":  null,
    "MerchantReference":  "",
    "PaymentReference":  null,
    "RetrievalReferenceNumber":  null,
    "LeadBankCbnCode":  null,
    "LeadBankName":  null,
    "SplitAccounts":  [],
    "TransactionDate":  "0001-01-01T00:00:00",
    "ResponseCode":  "Z1",
    "ResponseDescription":  "Transaction error"

Response Codes Description

When getting the status of a transaction, depending on the status, various response codes can be sent from the payment gateway.

| 00 | The transaction was Successful/Approved by the payers' bank. | | Z6 | Customer cancelled the transaction before payment was made. | | 51 | Insufficient funds to make payment.| | Z1 | This is a general response code. It implies there was an Error with the transaction (e.g. No card record, Pin tries exceeded, insufficient funds, etc.) More details will be provided in the ResponseDescription |

Home  CollegePAY WEB  Transaction Confirmation Leg  ReQuerying Pending Transactions

ReQuerying Pending Transactions

What are Pending Transactions?

When the transaction is started, it should be logged on your end, and it is logged as pending at that point.

Essentially, the transaction happens on two legs, the first is the payment leg where the actual debit will occur, and the second is the query leg where your system queries the web service to get the actual status for the transaction.

If for any reason, a timeout occurs on any of the systems involved, and for this reason, the query leg fails to confirm transaction status, the response on your end will remain pending. This is the kind of scenario that will warrant a reQuery. The reQuery is to [manually] redo the failed query leg that helps fetch the transaction response.

Note that in the above example, the transaction has already occurred at this point (after payment leg), and is already either failed or successful. The reQuery is to ensure that your system can be updated appropriately and the customer provided value if necessary.

ReQuery is basically a GetTransaction request called on command when required (i.e not related to a transaction). As with the GetTransaction above, the following parameters are sent:-

  • productid (product id as returned by CollegePAY)
  • amount (approved amount as returned by CollegePAY)
  • txn_ref (transaction reference as returned by CollegePAY)

In addition the application will timeout after roughly 10 minutes, and you will receive a failed transaction response if you reQuery. You should also endeavour to requery transactions with Response Code Z0 and 10001.

Test Merchant Details

Find below merchant details needed to perform transactions. Please note details vary based on the fee being used.

Kindly make use of the category that relates to your integration.


CollegePAY Test Payment URL: -

CollegePAY Test ReQuery URL: -


CollegePAY Live Payment URL: -

CollegePAY Live ReQuery URL: -

N300 Fee CollegePAY Merchant Details Table (NO SPLIT XML)

N300 Fixed Transaction Fee CollegePAY WEB Merchant Details Table for a Category 1 merchant\ (Maximum transaction amount N1,000,000)

Field Name Expected Value Comments
product_id 6207
pay_item_id 103
Mac Key CEF793CBBE838AA0CBB29B74D571113B4EA6586D3BA77E7CFA0B95E278364EFC4526ED7BD255A366CDDE11F1F607F0F844B09D93B16F7CFE87563B2272007AB3

N300 Fee CollegePAY Merchant Details Table (XML SPLIT ENABLED)

N300 Fixed Transaction Fee CollegePAY WEB Merchant Details Table for a Category 1 merchant\ (Maximum transaction amount N1,000,000)

Field Name Expected Value Comments
product_id 6207
pay_item_id 101
mac Key CEF793CBBE838AA0CBB29B74D571113B4EA6586D3BA77E7CFA0B95E278364EFC4526ED7BD255A366CDDE11F1F607F0F844B09D93B16F7CFE87563B2272007AB3

N200 Fee CollegePAY Merchant Details Table (NO SPLIT XML)

N200 Fixed Transaction Fee CollegePAY WEB Merchant Details Table for a Category 1 merchant\ (Maximum transaction amount N1,000,000)


Field Name Expected Value Comments
product_id 6207
pay_item_id 102
Mac Key CEF793CBBE838AA0CBB29B74D571113B4EA6586D3BA77E7CFA0B95E278364EFC4526ED7BD255A366CDDE11F1F607F0F844B09D93B16F7CFE87563B2272007AB3

N200 Fee CollegePAY Merchant Details Table (XML SPLIT ENABLED)

Show 102550100 entries


Field Name Expected Value Comments
product_id 6206
pay_item_id 102
mac Key 9A17E7F90B3D7B84255EBF299A4013C4B7C598916E0597DEF055F2D37232FA68C4C64A7F75CD3713196088BF6EEA380D62F5C584C9476B5263EB0B6A51B7742B

Merchant User Acceptance Testing

After a successful integration to WebPAY with the DEMO details, each merchant is required to request a test of the integration from Interswitch. This is to ensure the integration standard quality and security requirements. The requirements are details in a Do-It-Yourself (DIY) document sent to each new customer. The DIY document contains 10 Compulsory items and 8 Optional items. Click here to download a copy of the DIY Document.

Download Merchant Do-It-Yourself (DIY) Document

Compulsory Items (Items 1 -- 10)

Items 1 -- 10 must be achieved before any integration can be certified and taken live.

  1. Requirement:- You must have the InterSwitch logo on your site to differentiate our payment services from other ones you might have\ This is to ensure paying customers are aware of the cards accepted on your websiteUat 1
  2. Is the customer aware of the total amount he/she will be debited of before loading the payment page? Always inform the customer duly\ Inform the customer of the total amount of goods or services being purchased. This is equivalent to the amount being passed to the gateway (converted to Naira).Uat 2
  3. Are customers on your website registered? If no then you need to communicate their transaction reference number to them before they make payment so that they will have a reference value in case they have issues with their transactions. You should send a mail, text or you could print these details for them on the website with eye-catching prompt to note them.Uat 3bUat 3a
  4. When the payment page loads up, confirm that the amount displayed is correct.Uat 4
  5. After a transaction had been processed, certain information needs to be displayed to the customer. They include the following\ a. The transaction status in a very friendly way. For example, rather than just have "Insufficient Funds" as a response, you should have something like "Your transaction was not successful. Reason: Insufficient Funds". This is more descriptive.\ b. The transaction reference number which you sent to WebPAY for that transaction.\ c. The payment reference which is generated and returned by WebPAY.Uat 5aUat 5bUat 5c
  6. There are various response codes that can be returned by WebPAY along with their different descriptions. The objective here is to ensure that the customer gets the same description as sent by WebPAY. The website should NEVER customise WebPAY responses displayed to the customer.a. Successful transaction display\ b. Expired card transaction display\ c. Insufficient Funds transaction display\ d. Incorrect pin transaction\ e. Incomplete transaction displayUat 6aUat 6bUat 6c
  7. After a transaction has been completed successfully, you should send a mail containing the transaction details to the customerUat 7aUat 7b
  8. It is expected that you have a table that logs all transaction attempts on your website. When transactions IDs are generated, you are to log the transaction on that table and update when the responses returned. That way, you will be able to determine transactions that are still pending\ Pending transactions are transactions whose status is not known. Once you generate transaction ID's they're to be stored before the user us routed to the payment gateway, and updated after transaction is completed.Uat 8bUat 8cUat 8a
  9. For transactions that were described as pending, you need to have the means of confirming their status at Interswitch's end. You are to use the Web service query to do that. The response from this will then be used to update the transaction table accordingly.Uat 9aUat 9b
  10. A more administrative version/copy of the history table is needed at the admin end. This table might be more detailed than the customer's. The aim of this table is to provide 1st level support to the customer. The important fields to capture are the following\ a. Transaction date and time b. Transaction reference number c. Approved amount d. Response description e. Response code f. Transaction amount (what is to be approved. This could be optional)\ g. Customer name and ID (Optional) h. ReQuery feature to confirm the status of pending transactions.Uat 10

Optional Items (Items 11 -- 17)

  • Do you have instructions on your site that will guide the customers in making payments? These instructions will also include the processes that are not norm on your website. These instructions must be eye-catching so the customers never miss it.
  • Convention/elegance: have successful transaction details printed out in blue color and failed transaction details printed out in red color.
  • A support section must be provided showing the physical location of the company, telephone numbers and email addresses.
  • When customers are done with the transaction and have been redirected back to the confirmation page, you should let them know what to do next. For example, you can have a phrase "Click here to retry transaction or Go to someplace to do something". This is applicable for both failed and successful transactions. There is no hard fast rule to this. The whole idea is to maintain a flow all through transactions and retries.
  • For customers that have an account on the site, they are to be provided with a transaction histories table that details all their transaction attempts (Note the all). This will show all successful, pending and failed transactions. Do note that the status of failed transactions must be explicit. The same description employed on the confirmation page should be replicated here. If it was a failed transaction with an "Expired Card" response, then it must be the same in the history.
  • If the products for purchase on your site are not provided immediately then you need to inform the customer duly if they are available. In the case of services, ensure that the customer understands how the service will be rendered after payment.
  • If you are charging the customers a fee for the service rendered or the product purchased, ensure that they are informed as in Step 3.

XML SPLIT Bank Codes

Bank SPLIT Code
United Bank for Africa 7
First Bank 8
MainStreet 9
GTBank 10
Union Bank 11
WEMA Bank 16
Access Bank 31
Ecobank 47
Fidelity Bank 51
Access Bank (Diamond Bank) 72
Equitorial Trust Bank 75
Intercontinental Bank 89
Standard Chartered 109
Zenith Bank 117
Polaris Bank (SKYE Bank) 120
Sterling Bank 121
Keystone Bank 123
Enterprise Bank 125
CitiBank 126
Fin Bank 128
UNITY Bank 129
JAIZ Bank 261
Heritage Bank 307

Sample Codes


1)  Basic WebPAY Sample

  • Payment and Response Processing
  • Re-querying pending or completed Transactions



1 -- Basic WebPAY Sample

  • Payment and Response Processing
  • Re-querying pending or completed Transactions

2 -- CollegePAY X

  • Payment and Response Processing
  • SPLIT XML Enabled (Equal 3 way split)
  • Re-querying pending or completed Transactions
  • Transaction logging and History

3 -- ReQuery X

  • Re-querying pending or completed Transactions



  • Payment and Response Processing
  • SPLIT XML Enabled (3 way split)