End to end SMS encrypted money transfer logic. All users registered on LOKDON would have

• Phone number
• Username
• Email
• ApiKey
• Address
• Picture amongst others

Form input data for initiating the SMS based money transfer are recipient email, recipient phone number and amount sent.

• Recipient email – fully encrypted
• Recipient email – fully encrypted
• Recipient phone number – fully encrypted
• Sender email – fully encrypted
• Amount – fully encrypted

String receiverEmail = CipherControl.getInstance().encryptGenericData(recv_email);

String userPhoneNumber = CipherControl.getInstance().encryptGenericData(number);

String userSendEmail = CipherControl.getInstance().encryptGenericData(send_email);

String sentAmount = CipherControl.getInstance().encryptGenericData(amount);

All data above would be sent as a POST request to this API url For creating a session and profile of transaction.

M3Pin is stripped out by a POST request of these parameters

• Encrypted recipient email
• Encrypted recipient phone number
• With sender API Key

To this API url

On a success response, the session ID from the create session API, sent amount, recipient email, M3Pin of the recipient, all encrypted are sent as SMS string to the receiver phone number with a keyword CDR for the first leg. All messages are encrypted and unreadable except with the LOKDON app.

The receiver will decrypt the entire message after M3PIN of the receiver is extracted and decrypted to M2PIN. Thereafter, the receiver will read messages list from the LOKDON application (after M2PIN of receiver is matched) the receiver finds the message sent from the sender clearly decrypted by now, recipient takes further step to click on the reply button. Now the logic behind the reply click are as follows:

• Sender M3PIN is extracted from the message body decrypted and compared with the recipient M2PIN for a character length match if it matches to determine a valid M2PIN string if(!CipherControl.getInstance().decryptMpinFromSinglePosition(m3Pin+applicationController .getValueFromPerference(Constants.KEY_MPIN).charAt(10)) .equalsIgnoreCase(CipherControl.getInstance() .decryptTransactionSecurityPin(applicationController .getValueFromPerference(Constants.KEY_MPIN)))) { TastyToast.makeText(context,”Mpin Not Match”,TastyToast.LENGTH_SHORT,TastyToast.ERROR).show(); Return; }
• A session is created by POST parameters comprising of recipient encrypted email, phone number and api key to the API url
• Session message, M3PIN encrypt, amount and email are concatenated to a string and encrypted with our SMS encryption algorithm SmsEncryption.getInstance( ).getEncryptSms(messageText.toString( ), keyList.get(position)); Once completed SMS is sent to the sender for acknowledgement.

This leg is handled by the sender after a successful confirm message is sent from the recipient all in app

• Sender’s M3PIN is extracted from the message body decrypted and compared with the recipient’ M3PIN for a character length of 10 if it matches to determine a valid M2PIN string if(!CipherControl.getInstance().decryptMpinFromSinglePosition(m3Pin+applicationController .getValueFromPerference(Constants.KEY_MPIN).charAt(10)) .equalsIgnoreCase(CipherControl.getInstance() .decryptTransactionSecurityPin(applicationController .getValueFromPerference(Constants.KEY_MPIN)))) { TastyToast.makeText(context,”Mpin Not Match”,TastyToast.LENGTH_SHORT,TastyToast.ERROR).show(); Return; }
• The confirm payment API is accessed LEG A with parameters like sent amount, session message, sender phone number and receiver phone number all encrypted.
• M3Pin is stripped out from the other message body all encrypted with the SMS encryption algorithm SmsEncryption.getInstance( ).getEncryptSms(messageText.toString( ), keyList.get(position));
• SMS is sent with a confirm keyword to the recipient for the final leg of the SMS transaction.

• A must confirm the transaction in flow 3 by undergoing another ZKP. “I am A sealing that I did this transfer for you as agreed”
  This is second and the last ZKP by A.
• Sender M3Pin is extracted from the message body decrypted and compared with the recipient M3Pin for a character length of 10 if it matches to determine a valid m3pin string if(!CipherControl.getInstance().decryptMpinFromSinglePosition(m3Pin+applicationController .getValueFromPerference(Constants.KEY_MPIN).charAt(10)) .equalsIgnoreCase(CipherControl.getInstance() .decryptTransactionSecurityPin(applicationController .getValueFromPerference(Constants.KEY_MPIN)))) { TastyToast.makeText(context,”Mpin Not Match”,TastyToast.LENGTH_SHORT,TastyToast.ERROR).show(); Return; }
• The confirm payment API is accessed LEG B with parameters like sent amount, session message, sender phone number and receiver phone number all encrypted.
• On success complete payment is made and all necessary debit and credit would be initiated on both accounts i.e, the sender would be debited from the LOKDON wallet with sent amount while the recipient would be credited accordingly.

FYI

There is not much to write about. It’s just that where you have matching. Should be receivers m3pin added to the message is extracted, decrypted to the next mode m2pin. This iS compared to m2pin held locally or by the server.

• B must also second the confirmation by yet another ZKP to finalize the transaction.

POST params receiver email, phone number, sender email, sent amount, sent phone all encrypted with our algorithm.

• String receiverEmail = CipherControl.getInstance().encryptGenericData(recv_email);
• String userPhoneNumber = CipherControl.getInstance().encryptGenericData(number);
• String userPhoneNumber = CipherControl.getInstance().encryptGenericData(number);
• String userSendEmail = CipherControl.getInstance().encryptGenericData(send_email);
• String sentAmount = CipherControl.getInstance().encryptGenericData(m_amount);
• String sentPhone = CipherControl.getInstance().encryptGenericData(phoneNo);

API URL

On success a wallet object response is returned with data values related to the successful wallet to wallet cloud transfer