Payment Integration Methods
Please see below the different integration methods listed from easiest to most difficult:
With this integration, the merchant gains full access to an Ozow portal, where they can Ozow easily and Ozow quickly generate and send payment links to their customers via Ozow’s system. To create a payment request, all the merchant has to do is enter these Ozow simple details:
- The payment amount
- The customer’s name
- The reference expected on merchant’s bank statement (e.g. an invoice number)
- The payment link delivery method
Delivery of the payment link can be done in one of three Ozow convenient ways:
- SMS: The merchant requests the customer’s cell phone number and enters it into the payment request portal. Once the payment request is made, Ozow delivers an SMS with the payment link to the customer.
- Email: The merchant requests the customer’s email address and enters it into the payment request portal. Once the payment request is made, Ozow delivers an email with the payment link to the customer.
- QR Code: The merchant is served with an Ozow unique QR code. Their customer scans this QR code with their own mobile device, and Ozow’s payment process is initiated on said device.
With the payment request link integration, merchants also have the option to create Ozow many links in bulk. This option, however, does require the merchant to take ownership of the delivery methods, as Ozow only generates payment links for the merchant to distribute. Aside from this, Ozow also provides merchants with the option to make payment requests either static or dynamic, as well as the ability to stipulate the payment amount and/or bank reference.
Through this Ozow easy integration, the merchant will not require a website, coding skills or access to developers.
This integration method is quite simply an Ozow normal HTML form with text fields that is posted to Ozow. The customer is redirected from the merchant’s website to Ozow’s payment page to process their payment. Once their payment has been successful, Ozow redirects the customer back to the merchant’s website, as stipulated by the callback URL’s in the form’s post fields. Please note that there are a few optional fields that the merchant can use, of which you can find out more about by contacting us here.
Through this integration, the merchant will need Ozow few things, such as a website and a web developer with some knowledge of server-side scripting. To keep the integrity of the data being posted Ozow secure, a hash will also need to be generated server side, on the fly and posted through to Ozow with the form post fields. Generating a hash needs some server-side-scripting and therefore a small backend server is also required.
This integration method is Ozow great in alleviating the need to redirect the customer. All the merchant has to do is add a script file to their website, which pulls one of two Ozow simple payment screen types into their website:
- iFrame: Through iFrame, the merchant will have a degree of control over styling the payment screen, however, please note that iFrame is not compatible with all devices.
- Modal: Through Modal, the merchant will have virtually no control over the UX and styling of the payment screen, however, Modal is compatible with all types of devices.
Through the JS injection integration method, the merchant will require some things. Firstly, the merchant will need a website and a web developer with some knowledge of front-end scripting. To keep the integrity of the data being posted Ozow secure, a hash will also need to be generated server side, on the fly and posted through to Ozow with the form post fields. Generating a hash needs some server-side-scripting and therefore a small backend server is also required.
Ozow also provides an integration method that generates a URL link via an API. All the merchant has to do is make a call to Ozow’s API, passing through a few data fields stipulating payment details as well as identifying who the merchant is.
Authorization header fields need to be passed through in order to authenticate that the merchant is in fact who they claim to be. To keep the integrity of the data being passed Ozow secure, a hash needs to be generated, on the fly and posted through with the fields being sent through to Ozow’s API endpoint. Ozow will respond to successful API calls with a request ID and a payment link. The request ID can be used to check the status of the payment via an API call. The payment link can be sent by the merchant to their customers in any of the Ozow convenient formats:
- A button on a webpage or pdf invoice
- A link on a webpage or pdf invoice
- A QR code on a t-shirt, website, pdf invoice, banner etc
- A link delivered via SMS, email, USSD, in-app etc
Please note however that the merchant will be responsible for delivery and method of display of the payment link. Aside from this, the merchant will also need a back-end server, as well as a proficient back-end developer with front-end web skills
Payment System Plugins
We will help you integrate Ozow into your business
For the developers out there.
Step 1 – Post From Merchant Website
||Yes||A unique code for the site currently in use. A site code is generated when adding a site in the Ozow Merchant Admin section.|
||Yes||The ISO 3166-1 alpha-2 code for the user’s country. The country code will determine which banks will be displayed to the customer. Please note only South African (ZA) banks are currently supported by Ozow.|
||Yes||The ISO 4217 3 letter code for the transaction currency. Please note only South African Rand (ZAR) is currently supported by Ozow, so any currency conversion would have to take place before posting to the Ozow site.|
||Yes||The transaction amount. The amount is in the currency specified by the currency code posted.|
||Yes||The merchant’s reference for the transaction|
||Yes||The reference that will be prepopulated in the “their reference” field in the customers online banking site. This will be the payment reference that appears on your transaction history.|
|7. Optional1 8. Optional2 9. Optional3 10. Optional4 11. Optional5||
||No||Optional fields the merchant can post for additional information they would need passed back in the response. These are also stored with the transaction details by Ozow and can be useful for filtering transactions in the merchant admin section.|
||No||The customers name or identifier.|
||No||The Url that we should post the redirect result to if the customer cancels the payment, this will also be the page the customer gets redirect back to. This Url can also be set for the applicable merchant site in the merchant admin section. If a value is set in the merchant admin and sent in the post, the posted value will be redirected to if the payment is cancelled.|
||No||The Url that we should post the redirect result to if an error occurred while trying to process the payment, this will also be the page the customer gets redirect back to. This Url can also be set for the applicable merchant site in the merchant admin section. . If a value is set in the merchant admin and sent in the post, the posted value will be redirected to if an error occurred while processing the payment.|
||No||The Url that we should post the redirect result to if the payment was successful, this will also be the page the customer gets redirect back to. This Url can also be set for the applicable merchant site in the merchant admin section. If a value is set in the merchant admin and sent in the post, the posted value will be redirected to if the payment was successful. Please note that it would not be sufficient to assume the payment was successful just because the customer was redirected back to this page, it highly recommended that you check the response fields and as well as check the transaction status using our check transaction status API call.|
||No||The Url that we should post the notification result to. The result will posted regardless of the outcome of the transaction. This Url can also be set for the applicable merchant site in the merchant admin section. If a value is set in the merchant admin and sent in the post, the notification result will be sent to the posted value. Find out more in the notification response section in step 2.|
||Yes||Send true to test your request posting and response handling. If set to true you will be redirected to a page where you can select whether you would like a successful or unsuccessful redirect response sent back. Please note that notification responses are not sent for test transactions and the online banking payment is skipped. Accepted values are true or false.|
||Yes||SHA512 hash used to ensure that certain fields in the message have not been already after the hash was generated. Check the generate hash section below for more details on how to generate the hash.|