Step 2: Process Ozow Response

Ozow will send the following two posts back to the merchant:
Redirect Response
Notification Response

Redirect response

Depending on the payment completion status from Ozow, the response variables will be posted while redirecting the user to the applicable page. Please note that if the applicable URL was not sent in the post variables, or set for the merchant site in the merchant admin site, the user will not be redirected back to the merchant site, along with the post containing the response variables. The URL used will be determined as follows:

Error URL - An error occurred during the payment process and payment was NOT successful
Cancelled URL - The user opted to cancel during the payment process and payment was NOT successful
Success URL - The payment was successful

Use the hash response variable to verify the validity of the response. This process is further described in the response hash check section below. It's recommended that you use the notification response to verify the outcome of the transaction.

Notification response

We will post the response variables to the designated notification URL. Please note that if the notification URL (NotifyUrl) was not sent in the post variables, or set for the merchant site in the merchant admin site, we will not be able to send the notification post containing the response variables. Use the hash response variable to verify the validity of the response. This process is further described in the response hash check section below.

Please note:

While we do our utmost to ensure that duplicate notifications are not sent to the notification URL, at times there may be instances where multiple notifications are sent for the same transaction. As such, it is of the utmost importance that your system is built in a manner that caters for this scenario, i.e. if you receive multiple notifications for the same transaction your client/payer is not credited multiple times for the payment.

Response variables

PropertyTypeDescription
1.SiteCodeString (50)The site code sent to Ozow in the request post.
2.TransactionIdString (50)The transaction identifier generated by Ozow.
3.TransactionReferenceString (50)The merchant's transaction reference sent in the request post's TransactionReference variable.
4.AmountDecimal (9,2)The transaction amount. The amount is in the currency specified by the currency code posted.
5.StatusString (50) The transaction status. Possible values are:
1. Complete - The payment was successful.
2. Cancelled - The payment was cancelled.
3. Error - An error occurred while processing the payment.
4. Abandoned – The payment was abandoned.
5. PendingInvestigation – An inconclusive result was received by the bank and the payment needs to be verified manually.
6. Pending – The status cannot be determined as yet but will be reposted to the notification URL as soon as it has been determined. Merchants not using the notification URL will receive a PendingInvestigation status.
6.Optional1
7.Optional2
8.Optional3
9.Optional4
10.Optional5
String (50)Optional fields sent in the request post.
11.CurrencyCodeString (3)The transaction currency code sent in the request post.
12.IsTestboolWhether or not the original request was a test request. Possible values are true or false.
13.StatusMessageString (150) Message regarding the status of the transaction. This field will not always have a value. This is a user friendly message that can be displayed to the user e.g. User cancelled transaction.
14.HashString (100)SHA512 hash used to ensure that certain fields in the message have not been altered after the hash was generated. Check the generate hash section below for more details on how to validate the response variables using the hash.
15.SubStatus
(See full list below)
String (50)The transaction sub status for failed transactions. The value provides an indication as to why the payment failed.

Some examples:
• Unclassified – Failure scenario has not been mapped
• InsufficientFunds - User did not have sufficient funds
available to complete the payment

While there are several sub-statuses, they have not been included here as they are strictly for reporting.
16.MaskedAccountNumberString (50)The masked account number the payment was made from.

If account number is 12 or more digits then the first and last four digits are unmasked e.g. 1234567898765 will be masked as
1234*****8765

If the account number is less than12 digits then the first and last 3 digits are left unmasked e.g. 123456789 will be masked as 123***789

This is not available by default and a request by the merchant must be submitted along with a justification for requiring this information.
17.BankNameString (50) The name of the bank the payment was made from.
18.SmartIndicatorsString (500) Some Ozow merchants have requested this information as they use this in their own processes. The can be ignored unless you have a purpose and application for this information. The application of these indicators are for the merchant’s discretion and in isolation do not constitute any action to be taken by the merchant.

The field will contain a pipe delimited list of the following values if they are applicable e.g. HIGH_VALUE | FIRST_OZOW :

HIGH_VALUE – If a soft limit is configured on the site and the amount paid is higher or equal to the configured limit
FIRST_OZOW – First time a user has paid using Ozow
FIRST_MERCHANT – First time a user has paid the merchant using Ozow
NEW_OZOW – User has paid using Ozow for the first time in the past seven days
NEW_MERCHANT - User has paid the merchant using Ozow for the first time in the past seven days

SubStatus - List

The list refers to property 15. SubStatus The transaction sub status for failed transactions. The value provides an indication as to why the payment failed, each variant response is accounted for by number.

SubStatusNumber
Unclassified0
AutomationError1
AutomationStepUnhandled2
BankingLimitExceeded3
LoginError4
PushAppMessageDeclined5
PushAppMessageError6
AutomationInactivityTimeout7
CustomerAccountError8
BankNotResponding9
CaptchaRequired10
MerchantAccountError11
OnlineBankingProfileError13
InvalidPaymentReference14
AutomationStartupFailure15
BeneficiaryOrPaymentConfirmationFailure16
DuplicatePayment17
OnlineBankingTimeout19
NoAvailableAccounts21
OnlineBankingUnavailable22
BankTechnicalError23
SimSwapBlock24
BankNotice25
InsufficientFunds26
NoInternetBanking28
PaymentConfirmationError29
AutomationLoopDetected31
OnlineBankingVersionMigration35
CreditCardNotAllowedMerchant36
FraudulentActivity37
BankPaymentError38
OnlineBankingAction39
OtpInvalidError40
InsufficientAccess41
PasswordChangeRequired42
PublicBeneficiaryError43
PaymentDetailsVerificationError44
InvalidCustomerInput45
AutomationPopulationError46
ReceiptTimeout47
NoLoginTimeout48
UserCancelled49
CancelToRetry50
BrowserExitOrRedirect51
AutomationNotStarted52
LoginPageNotReached53
NoBankSelected54
AnomalousHighValueForUser55

Response hash check

Follow these steps to validate the response:

  1. Concatenate the response variables 1-13, in the order they appear in the response variables table.
  2. Append your private key to the concatenated string. Your private key can be found in the merchant details section of the merchant admin site.
  3. Convert the concatenated string to lowercase.
  4. Generate a SHA512 hash of the lowercase concatenated string.
  5. Compare generated hash to the hash value in the response variables.

🚧

Warning!

Some implementations of SHA512 drop the leading zeros. It is advisable to trim the leading zeros from the received and calculated hashes when comparing.

Only include variables listed in the response variables table above.