Piga Kura: Uhitaji wa Online Payment API Rahisi

Developer Unatumiaje Kulipa/Kulipwa na Wateja wako Online

  • Total voters
    29
Mtangoo

Mtangoo

JF-Expert Member
Oct 25, 2012
6,167
5,602
Kumekuwa na malalamiko mengi juu ya kukosekana kwa API bora ya malipo Tanzania.
Piga kura yako hapa na uache maelezo ambayo ungependa mamlaka husika zifanyie kazi.

Pamoja nu kuelezea mambo yanayokosekana katika malipo online (ugumu na masumbufu yake) jaza kura hapo juu na utuambie unalipwaje kwa sasa. Na kama project yako imeshidwa ku launch kwa sababu hiyo basi utoe maelezo kidogo (usiweke idea yako tafadhali isije kuibiwa)

NB: usiishie kulalamika. Weka Maoni/Matatizo yako yafanyiwe kazi. Na kwa wale ambao hawaelewi kinachoendelea tafadhali soma kimya kimya tu. Huu ni uzi muhimu sana kwa maendeleo ya nchi.
 
Mkuu unafahamu vema kuwa the mind works better subconsiously. Kwahiyo since you have mentioned this our minds will come up with ideas in due time. For the time being I will write what comes into mind. Note that I have personally never implemented an online payments API ya bongo due to hofu ya reliability and 'closed-ness' ya providers. So I will just say what I think should be implemented. Most will be rant and random thoughts.

1. The entire reference-number based system should be dropped. There are too many components and communication channels and if any of them breaks the results are undefined.
The flowchart ya user initiates transaction > merchant tells user what ref.no to use > user goes to payment service > user makes payment > user receives sms confirmation with transaction ID > user tells merchant the transaction ID > merchant confirms transaction should be replaced with something shorter. The components that rely on SMS should specifically be targeted because of its unreliability.

According to the USSD protocol, a server / USSD app can initiate a USSD session. Isn't it possible for the flowchart to be user initiates the payment from the merchant's site > the merchant contacts the payment service provider via the API > the provider immediately asks for confirmation from the user via USSD > the payment service performing the transaction and notifying the merchant?
 
ISO M.CodD said:
Mkuu unafahamu vema kuwa the mind works better subconsiously. Kwahiyo since you have mentioned this our minds will come up with ideas in due time. For the time being I will write what comes into mind. Note that I have personally never implemented an online payments API ya bongo due to hofu ya reliability and 'closed-ness' ya providers. So I will just say what I think should be implemented. Most will be rant and random thoughts.

1. The entire reference-number based system should be dropped. There are too many components and communication channels and if any of them breaks the results are undefined.
The flowchart ya user initiates transaction > merchant tells user what ref.no to use > user goes to payment service > user makes payment > user receives sms confirmation with transaction ID > user tells merchant the transaction ID > merchant confirms transaction should be replaced with something shorter. The components that rely on SMS should specifically be targeted because of its unreliability.

According to the USSD protocol, a server / USSD app can initiate a USSD session. Isn't it possible for the flowchart to be user initiates the payment from the merchant's site > the merchant contacts the payment service provider via the API > the provider immediately asks for confirmation from the user via USSD > the payment service performing the transaction and notifying the merchant?
Click to expand...

Why not drop the whole ussd thing and have phone/pin combination to authorize a payment and maybe a confirmation text or any other layer as second factor of authentication
 
ub16 said:
Why not drop the whole ussd thing and have phone/pin combination to authorize a payment and maybe a confirmation text or any other layer as second factor of authentication
Click to expand...
Only if the API has a different PIN for the customer apart from the customer's PIN with the payment service provider. Also, the merchant can't be trusted with the PIN so this would necessitate all transactions to be handled by an online interface belonging to the API provider, similar to PayPal's model.

Authentication still needs to be performed with the payment service provider since we know how careless Tanzanians are with their PINs.

There is a major flaw with server-initiated USSD sessions, the user cannot verify the initiator (unlike https). Phishing attacks could be conducted so care must he taken implementing this route.

Using SMS as the 2FA is plausible if the process is structured yet simple enough for tge users.
 
Natumia MPESA kwa wateja wangu waliopo hapa Bongo na abroad ni Paypal,, I would recommend them to others as well
 
Kaliro X said:
Natumia MPESA kwa wateja wangu waliopo hapa Bongo na abroad ni Paypal,, I would recommend them to others as well
Click to expand...
You wouldn't want to force your customers to one service provider, would you? The whole point of having a single API for all the providers (including banks possibly) is to offer flexibility.
 
I also thought about autonomous or recurring payments where the user authorizes the charge frequency and amount and the merchant can request the API to provide the payment when it is due.

Escrow should be implemented by the API for easy reversal of a transaction by either side
 
There is tigo secure solution exist nw...just read this attachement,only few procedure and allow the developer to use his ownl wallet if he had one
 

Attachments

  • TigoSecure Solution for Corporate.pptx
    1.6 MB · Views: 128
babumufty said:
There is tigo secure solution exist nw...just read this attachement,only few procedure and allow the developer to use his ownl wallet if he had one
Click to expand...

While this looks great my biggest problem with these APIs has been lack of proper documentation and clear information on how to get on-boarded. Last I checked tigos "documentation" was more of a technical document on how the system works rather than a document to get a developer started.
 
ub16 said:
While this looks great my biggest problem with these APIs has been lack of proper documentation and clear information on how to get on-boarded. Last I checked tigos "documentation" was more of a technical document on how the system works rather than a document to get a developer started.
Click to expand...
I gree dat...for my opinion they should implement something like paypal sandbox,show the procedure how to intergrate with the system..
 
Great contribution guys.
What are the good bad and ugly of our current payment systems apart from what is said above? What else is missing?
 
Ninahangaika sana kwa kushindwa kuuza taaluma flani online kwasababu platform nyingi zinahitaji paypal kunilipa lakini Tanzania haikubali malipo ya paypal, jamani BOT ruhusuni kupokea hela kwa PAYPAL, raia tunakosa nafasi za kutengeneza pesa online.
 
Sokoro waito said:
Ninahangaika sana kwa kushindwa kuuza taaluma flani online kwasababu platform nyingi zinahitaji paypal kunilipa lakini Tanzania haikubali malipo ya paypal, jamani BOT ruhusuni kupokea hela kwa PAYPAL, raia tunakosa nafasi za kutengeneza pesa online.
Click to expand...
Tupo kwenye boti moja wangu. Nilitaka kufundisha online kupitia udemy but no help. Inauma sana.
 
You must log in or register to reply here.

Similar Discussions

Back
Top Bottom
Forums
New posts
Post thread
Back