Streamlined API

[gilokimu]

I believe the API could be streamlined to support the common use cause of a business that wants to start receiving payments. ie

//Final implementation
Daraja daraja = new Daraja.Builder() //could be injected or single instanced
                 .setConsumerKey("")
                  .setConsumerSecrtet("")
                    .setCallbackUrl("")
                    .setBusinessShortCode("")
                    .setAccountType(TransactionType.CustomerBuyGoodsOnline)
                    .setParty(""); //not sure if partyA or partyB

//simpler API requests that returns the DarajaListener
daraja.pay("phone", "amount", "description"); //creates an LNMExpress class from Daraja and does api request

Currently, LNMExpress class holds to much scope, some of which should be held in the Daraja class.

I am willing to create a PR to demonstrate the same

[jumaallan]

Hi @gilokimu

The PR is much welcome 💯

[jumaallan]

I have invited you as a collaborator on the project as well 👍 🚀

[gilokimu]

Thanks, Maybe next weekend.

[jumaallan]

Awesome 🦅 🚀

[gilokimu]

Hey, forgot to respond here. I took a look at the API and wasn't sure how the other endpoints fit in context of android app, while I can still implement it for the sake, I did want to take a dev centric approach and not replicate the API given. I am still willing to take a stub at it and so any pointers will help.

TL;DR How do business use the API endpoints declared?

[jumaallan]

The rest of the API's would not work on the Android SDK, as the callback URLs need to be specified, which can be a bit difficult because the phone IP could keep on changing depending on the network it is connected to. Ideally, if we could manage to solve the IP issue, we could have the whole sdk setup on this SDK

[jumaallan]

We might have to update the README when we are done with this PR

[gilokimu]

Yeah, and the common use case would be to have server side handle the callback. I will restructure the current API implementation then

[jumaallan]

That would be the most appropriate use case, yes

[jumaallan]

@gilokimu

I might have an idea we can look at. Do you see how Firebase works, i.e the Cloud Messaging or Remote Config for example, Firebase is able to get your device regardless of the connected network you are connected to. The way I see it, its like they have a way to ping your device i.e in a callback way. If we are able to look at this, we could make the whole SDK work in the Android SDK. Let me get in touch with you actually, but we can move on with the discussion here

[gilokimu]

I am using cloud functions to get a baseUrl and I am able to receive the callback from Mpesa, at the moment I am getting the error : "The ReceiverParty information is invalid" but this is a few minutes into it. The idea is to create a payment request on firebase as well and have the cloud function validate it - That answers that bit.

2. Code restructure see this PR #25 :

   Daraja.Builder(Config.CONSUMER_KEY, Config.CONSUMER_SECRET)
               .setBusinessShortCode(Config.BUSINESS_SHORTCODE)
               .setPassKey(AppUtils.getPassKey())
               .setTransactionType(Config.ACCOUNT_TYPE)
               .setCallbackUrl(Config.CALLBACK_URL)
               .setEnvironment(Env.SANDBOX)
               .build();

   And to make payment Request

   public DarajaListener<LNMResult> makePaymentRequest(
           String token,
           String phoneNumber,
           String amount,
           String accountReference,
           String description,
           final DarajaListener<LNMResult> listener
   )

Still WIP - I do want to check the correct implementation for the access token and listeners

This is a very good guide : https://peternjeru.co.ke/safdaraja/ui/ and made things clear

[jumaallan]

Let me go through it

[gilokimu]

I think its better now. We should decide on way forward around the lib API class v2/Daraja.java and whether we should deprecate the old approach. I have also added the items I have been attempting into the project tab.

[jumaallan]

We can deprecate the v1, and roll out v2. We can merge all unfinished work, review and roll out the v2 update

[gilokimu]

Ok, I will create stable version tomorrow morning that you can merge. I will also review current open PR, I will keep some things in that PR - not all

[gilokimu]

A few merge requests later, I am done.

This is another breaking change for anyone who is using the earlier version. Just review and let me know

[jumaallan]

On it

A few merge requests later, I am done.

This is another breaking change for anyone who is using the earlier version. Just review and let me know

[jumaallan]

On it

A few merge requests later, I am done. This is another breaking change for anyone who is using the earlier version. Just review and let me know

Merged PR #29

[jumaallan]

After 2 years, haha

Can we work on updating the documentation on the README? @gilokimu

[jumaallan]

Closing this issue, for being stale for a while now 😶‍🌫️