Do It Yourself
Website URL? =
REPLACE ALL SCREEN SHOTS WITH YOUR OWN CORRESPONDING PAGES
Step 1
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.
(Yes) (No)
(Check the box)
Step 2
Can customers navigate seamlessly through your site pages? Free of errors and unavailable pages? Ensure that customers are thoroughly informed if they have to do something a certain way. For example: Phone number format is +234 XXX XXX XXXX as oppose to the default format
(Yes) (No)
Step 3
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.
(Yes) (No)
Step 4
You must have the Interswitch logo on your site to differentiate our payment services from other ones you might have.
(Yes) (No)
Step 5
Is the customer aware of the total amount he/she will be debited of before loading the payment page? Never assume this. Always inform the customer duly.
(Yes) (No)
Step 6
If you are charging the customers a fee for the service rendered or the product purchased, ensure that they are informed as in Step 5
(Yes) (No)
Step 7
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
(Yes) (No)
Step 8
Is the payment page loading as it should? If you are opening the page on a new page, ensure that the request string is not visible on the address bar.
If you are using pop ups, ensure that the background window is locked down so you do not have multiple instances of the same payment. If you are employing iframes, ensure that the page loads and aligns with your webpage as it should.
(Yes) (No)
Step 9
When the payment page loads up, confirm that the amount displayed is correct. Here the amount you passed in kobo format should be reflected in the naira format. No differences.
(Yes) (No)
Step 10
This is very critical. When transactions return the “00” response code (meaning approved transactions), you must confirm that the approved amount is the same with what is logged in your database.
The Webservice approach to requerying the transactions must be employed. Relying on the values in the browser is not 100% secure. Note that using these values is at your own risk.
After a transaction had been completed successfully, you should send a mail containing the transaction details to the customer
Here is a quick way to simulate a scenario where the amount approved is different from what it should be
•Initiate a transaction. (Here you would have generated the merchant ID & logged the transaction in your db/session)
•When you get to the payment page, pause. Do not enter your card details yet.
•Go back to your db log/session and change the amount for that transaction. (Note that at this point the amount on the payment page and the one in the db/session will be different)
•Go back to the payment page and carry out the transaction. Ensure the card details are correct to give you an approved transaction.
•When the response is returned. Ensure you compare the amount before giving value.
(Yes) (No)
Step 11
After a transaction had been processed, certain information needs to be displayed to the customer. They include the following
•The transaction status in a very friendly way. For example, rather than just have “Incorrect PIN” as a response, you should have something like “Your transaction was not successful. Reason: Incorrect PIN”. This is more descriptive.
•The transaction reference number which you sent to WebPAY for that transaction.
•The payment reference which is generated and returned by WebPAY.
(Yes) (No)
Step 12
Now 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 customize WebPAY responses displayed to the customer
For example, an Invalid Card Number response should not be displayed to the customer as “Invalid Card”. These are two different responses with varying meanings. Let’s have an explicit description in this regard.
You should test these different scenarios below by using the different cards below
(Yes) (No)
Successful transactions
6274807700000007/6278050000000007
July 2013
0000
Incorrect PIN
5060990330000003410
April 2013
0000
Invalid card number
6274807700000048
July 2013
0000
No card Record
506099033000000339
April 2013
0000
Customer cancellation
(Aka No transaction Record)
Click on the cancel button on the payment page.
Expired Card
5060990330000003402
April 2013
0000
Insufficient Funds
5060990330000003436
April 2013
0000
Step 13
Convention/elegance: have successful transaction details printed out in blue color and failed transaction details printed out in red color.
(Yes) (No)
Step 14
Transaction references must be unique for every transaction attempt regardless of whether it is the same order or the same service. You transaction length must not be less than 6 digits and it must not be greater than 16 digits.
Transaction format must be purely digits.
(Yes) (No)
Step 15
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
(Yes) (No)
Step 16
A support section must be provided showing the physical location of the company, telephone numbers and email addresses.
(Yes) (No)
Step 17
After a transaction had been completed successfully, you should send a mail containing the transaction details to the customer
(Yes) (No)
Step 18
It is expected that you have a table that logs all transaction attempts on your website.
When transaction ids are generated, you are to log the transaction on that table and update when the responses are returned.
That way, you will be able to determine transactions that are still pending
(Yes) (No)
Step 19
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
(Yes) (No)
Step 20
Now for those transactions that were described in step 18 as pending, you need to have the means of confirming their status at Interswitch's end.
You are to use the Webservice query to do that. The response from this will then be used to update the transaction table accordingly.
(Yes) (No)
Step 21
Response code 14 means Invalid Card Number. Is that the same on your website? Ensure that the codes are mapped against their corresponding descriptions. This is different from step 12. Here you are ensuring that the transaction code 55 is mapped to “Incorrect PIN” and not “Insufficient funds”
(Yes) (No)
Step 22
A more administrative version/copy of the table in step 19 is needed at the admin end. It might be the same table or different but this table might be more detailed then 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
- Transaction date and time
- Transaction reference number
- Approved amount
- Response code
- Response description
- Transaction amount (what is to be approved. This could be optional)
- Customer name and ID (Optional)
- Requery feature to confirm the status of pending transactions.
(Yes) (No)