The transaction flow entails the processes that has been put in place to ensure the integrity of transactions. A request is only seen as complete when a response is received for that request. When no response is received for these requests, it could mean a lot of things; it could be that the request was honored but the response was not received, it could equally be that the request did not arrive at all. However, when this happens, for requests like the debit, enquiry or place lien a reversal will be initiated. But when a response is not received for a reversal or a debit lien, the request will be repeated severally until a response is received. It will be good to note here that the reversal request for the place lien will be sent as a debit lien request with an amount of 0.<\/p>\n\n\n\n

Therefore a transaction request (debit, enquiry and place lien requests) will only be sent once for a particular transaction, if no response is received a reversal request for that particular transaction will be sent afterwards. For a reversal or debit lien request, if no response is received, the reversal or debit lien request will continue to be sent till a valid response is received. This means the fintech need to properly handle several reversals\/debit lien and make sure to only honor one of same reversal\/debit lien request sent severally.<\/p>\n\n\n\n

3.0 Transaction Type<\/h3>\n\n\n\n

The transaction type determines how the transaction should be treated. At the moment, we will only be treating 5 transaction types; DEBIT, ENQUIRY, REVERSALS, PLACE LIEN and DEBIT LIEN.<\/p>\n\n\n\n

The fiintechs are expected to implement and expose endpoints for these transaction types.<\/p>\n\n\n\n

DEBIT<\/strong>: the debit endpoint will be called whenever a debit is to be done on the wallet. This debit can be of any kind, goods & services, withdrawal etc.<\/p>\n\n\n\n

ENQUIRY<\/strong>: the enquiry endpoint will be called whenever an inquiry is to be done on the account. It can be balance enquiry, name enquiry etc<\/p>\n\n\n\n

REVERSAL<\/strong>: the reversal endpoint is called whenever a debit that has occurred on the wallet needs to be undone.<\/p>\n\n\n\n

PLACE LIEN: <\/strong>the place lien endpoint will be called for the authorization requests of a dual messaging. It should place a lien on the wallet for a particular amount.<\/p>\n\n\n\n

DEBIT LIEN: <\/strong>the debit lien endpoint will be called for the completion of the dual messaging. It should debit the lien that has been place.<\/p>\n\n\n\n

4.0 Response Codes<\/h3>\n\n\n\n

The response code is the value that particularly determines the status of the transaction. Since there should always be a response for every request, this response should have a way of telling what the status of the transaction is, this is what the response code does. The response code for this project is limited to the response codes listed below. If any response code is received and is not within the listed response codes, the transaction response is treated as an invalid transaction response regardless of what the status might have been on the fintech. If this happens and the response was for a debit request, a reversal will be sent for that transaction. If the response was for a reversal request, another reversal request will be sent.<\/p>\n\n\n\n

The valid response codes are as follows:<\/p>\n\n\n\n

Status<\/th>	Response Code<\/th><\/tr><\/thead>
Successful<\/td>	00<\/td><\/tr>
Do not honor<\/td>	05<\/td><\/tr>
Error<\/td>	06<\/td><\/tr>
Invalid transaction<\/td>	12<\/td><\/tr>
Invalid amount<\/td>	13<\/td><\/tr>
Unable to locate record<\/td>	25<\/td><\/tr>
Function not supported<\/td>	40<\/td><\/tr>
Lost card, pick-up<\/td>	41<\/td><\/tr>
Account closed<\/td>	45<\/td><\/tr>
Not sufficient funds<\/td>	51<\/td><\/tr>
Exceeds withdrawal limit<\/td>	61<\/td><\/tr>
Exceeds withdrawal frequency<\/td>	65<\/td><\/tr>
Not reachable\/Issuer or switch inoperative<\/td>	91<\/td><\/tr>
Duplicate transaction<\/td>	94<\/td><\/tr><\/tbody><\/table>\n\n\n\n 5.0 Transaction Reference Number<\/h3>\n\n\n\n The transaction reference is a unique string used to identify every transaction. Every transaction, regardless of the transaction type will have a unique transaction reference. A reversal request will however, have the transaction reference of the original transaction it’s trying to reverse. This original reference number is found only in reversal requests.<\/p>\n\n\n\n The several repeats of the reversal request, will all have a transaction reference which will be same as the first reversal request. This means that when a reversal request for a particular transaction is sent several times, they will all have the same transaction reference.<\/p>\n\n\n\n 6.0 Transaction Amount<\/h3>\n\n\n\n This is the amount that is sent both in the request and\/or in the response. For the purpose of this project the transaction amount will always be in minor. This means that for every request that will be sent and for every response that will be received, the transaction amount is always expected to be in minor.<\/p>\n\n\n\n e.g 100 naira in minor should be 10000.<\/p>\n\n\n\n 7.0 Terminal Type<\/h3>\n\n\n\n The terminal type is a 2 digit character that defines the terminal the transaction originated from. The below table shows what the different values identify.<\/p>\n\n\n\n Terminal Type<\/th> Terminal<\/th><\/tr><\/thead> 00<\/td> Administrative terminal<\/td><\/tr> 01<\/td> POS terminal<\/td><\/tr> 02<\/td> ATM<\/td><\/tr> 03<\/td> Home terminal<\/td><\/tr> 04<\/td> Electronic Cash Register (ECR)<\/td><\/tr> 05<\/td> Dial terminal<\/td><\/tr> 06<\/td> Travellers check machine<\/td><\/tr> 07<\/td> Fuel machine<\/td><\/tr> 08<\/td> Scrip machine<\/td><\/tr> 09<\/td> Coupon machine<\/td><\/tr> 10<\/td> Ticket machine<\/td><\/tr> 11<\/td> Point-of-Banking terminal<\/td><\/tr> 12<\/td> Teller<\/td><\/tr> 13<\/td> Franchise teller<\/td><\/tr> 14<\/td> Personal banking<\/td><\/tr> 15<\/td> Public utility<\/td><\/tr> 16<\/td> Vending<\/td><\/tr> 17<\/td> Self-service<\/td><\/tr> 18<\/td> Authorization<\/td><\/tr> 19<\/td> Payment<\/td><\/tr> 20<\/td> VRU<\/td><\/tr> 21<\/td> Smart phone<\/td><\/tr> 22<\/td> Interactive television<\/td><\/tr> 23<\/td> Personal digital assistant<\/td><\/tr> 24<\/td> Screen phone<\/td><\/tr> 25<\/td> Business banking<\/td><\/tr> 90<\/td> E-commerce – No encryption; no authentication<\/td><\/tr> 91<\/td> E-commerce – SET\/3D-Secure encryption; cardholder certificate not used (non-authenticated)<\/td><\/tr> 92<\/td> E-commerce – SET\/3D-Secure encryption; cardholder certificate used (authenticated)<\/td><\/tr> 93<\/td> E-commerce – SET encryption, chip cryptogram used; cardholder certificate not used<\/td><\/tr> 94<\/td> E-commerce – SET encryption, chip cryptogram used; cardholder certificate used<\/td><\/tr> 95<\/td> E-commerce – Channel encryption (SSL); cardholder certificate not used (non-authenticated)<\/td><\/tr> 96<\/td> E-commerce – Channel encryption (SSL); chip cryptogram used, cardholder certificate not used<\/td><\/tr><\/tbody><\/table>\n\n\n\n 8.0 Validating the created endpoints<\/h3>\n\n\n\n In a bid to make the endpoint validation easier, a postman test collection has been created to permit an automated test and validation of several test cases, you can import this collection from here (https:\/\/www.getpostman.com\/collections\/4c990a0e8ffe90c7988d<\/a>). Run this collection against the host where the app is deployed and be sure the tests in this collection pass.<\/p>\n\n\n\n Note: The variable for this collection is configured within the collection. So be sure the check the variables within this collection to supply the necessary details.<\/strong><\/p>\n\n\n\n For the test private key, any random key can be used while the development is ongoing, but the test private key will be shared once the development, validated and the created endpoints shared with the support engineer in ISW (be sure to update the app with this new private key).<\/p>\n\n\n\n It will be important to note that the path of the endpoints to be created should exactly match the path as specified below in the api specification section.<\/p>\n","protected":false},"author":228,"featured_media":0,"parent":0,"menu_order":2,"comment_status":"open","ping_status":"closed","template":"","meta":{"spay_email":""},"doc_tag":[],"_links":{"self":[{"href":"https:\/\/sandbox.interswitchng.com\/docbase\/wp-json\/wp\/v2\/docs\/4157"}],"collection":[{"href":"https:\/\/sandbox.interswitchng.com\/docbase\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/sandbox.interswitchng.com\/docbase\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/sandbox.interswitchng.com\/docbase\/wp-json\/wp\/v2\/users\/228"}],"replies":[{"embeddable":true,"href":"https:\/\/sandbox.interswitchng.com\/docbase\/wp-json\/wp\/v2\/comments?post=4157"}],"version-history":[{"count":2,"href":"https:\/\/sandbox.interswitchng.com\/docbase\/wp-json\/wp\/v2\/docs\/4157\/revisions"}],"predecessor-version":[{"id":4161,"href":"https:\/\/sandbox.interswitchng.com\/docbase\/wp-json\/wp\/v2\/docs\/4157\/revisions\/4161"}],"next":[{"title":"Fintech Card Processing (Spec Document) V2","link":"https:\/\/sandbox.interswitchng.com\/docbase\/docs\/fintech-card-processing-spec-document-v2\/","href":"https:\/\/sandbox.interswitchng.com\/docbase\/wp-json\/wp\/v2\/docs\/4398"}],"prev":[{"title":"Transfer Service Core API Documentation","link":"https:\/\/sandbox.interswitchng.com\/docbase\/docs\/transfer-service-core-api-document\/","href":"https:\/\/sandbox.interswitchng.com\/docbase\/wp-json\/wp\/v2\/docs\/4133"}],"wp:attachment":[{"href":"https:\/\/sandbox.interswitchng.com\/docbase\/wp-json\/wp\/v2\/media?parent=4157"}],"wp:term":[{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/sandbox.interswitchng.com\/docbase\/wp-json\/wp\/v2\/doc_tag?post=4157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}