Requesting a Payment
The following steps summarize an in-app payment request:
- 3rd party backend uses the Scan to Pay API to create a transaction code (which contains the amount, references, etc.).
- The 3rd party app invokes the intent passing in this newly created code.
- The Scan to Pay in-app library will facilitate the payment and return a result and reference indicating the payment status to the calling activity.
-
- The 3rd backend will then query the Scan to Pay system with the returned reference to guarantee the payment status. Alternatively, the 3rd backend will query itself to see if Scan to Pay has notified it of a new payment.
-
Note
It is imperative that the 3rd party app does not trust the library's result as the final status. A backend API call must be done to verify the payment status.
Invoking the Payment Intent
The following snippet illustrates how to invoke the payment request Intent:
Intent intent = new Intent(context, LibLiteActivity.class);
intent.putExtra(LibLiteActivity.IN_CODE, "1234567890");
intent.putExtra(LibLiteActivity.IN_API_KEY, "APIKEY");
intent.putExtra(LibLiteActivity.IN_HASH, “HASH KEY");
intent.putExtra(LibLiteActivity.IN_SYSTEM, "LIVE"); context.startActivityForResult(intent, 10);
Values passed to the LibLiteActivity
Name | Type | Description |
---|---|---|
LibLiteActivity.IN_CODE | String | This is the code created by calling the Scan to Pay API representing the transaction. |
LibLiteActivity.IN_API_KEY | String | This is the API key provided by Oltio/UKheshe that will enable the library to be used. This can be found on the Scan to Pay Portal under the Lib Lite Tokens menu item |
LibLiteActivity.IN_SYSTEM | String | This value can be “LIVE” or “TEST”, representing the Scan to Pay backend system to connect to. |
LibLiteActivity.IN_HASH | String | This allows capability for the app to read the SMS for registration. Details on how to generate the HASH key can be found here. |
LibLiteActivity.IN_SUGGESTED_MSISDN | String | This is an optional field if you know the clients mobile number. |
Handling the Payment Response
The following snippet illustrates how to handle the response from the LibLiteActivity:
SHARDUL TO PROVIDE
protected void onActivityResult(int requestCode, int resultCode, Intent data) { switch (requestCode) {
case 10:
Name | Type | Description |
---|---|---|
LibLiteActivity.LIBLITE_ERROR | Returned if an error has occurred before the payment | – This indicates the type of error that occurred. See the error table below LibLiteActivity.OUT_LOCATION - This is the location of the error. This can be used to debug the error when requesting support from Oltio |
LibLiteActivity.LIBLITE_PAYMENT_SUCCESS | Returned on payment success | LibLiteActivity.OUT_TX_REFERENCE - This is the reference for the transaction. This reference will be used to tie up the transaction on the 3rd party backend system. |
LibLiteActivity.LIBLITE_PAYMENT_FAILED | Returned if the payment failed | LibLiteActivity.OUT_TX_REFERENCE - This is the reference for the failed transaction in the event the 3rd party needs to request more information regarding the failure. |
LibLiteActivity.LIBLITE_USER_CANCELLED | Returned if the user aborted the process | LibLiteActivity.OUT_LOCATION - This is the location where the user aborted. This can be used to determine where the user is dropping off. |
LibLiteActivity.LIBLITE_INVALID_CODE | Returned if the code that was passed to the LibLiteActivity is invalid | None. |
Updated about 2 years ago