# Glossary > The technical terms used across the Ozow documentation. Source: https://hub.ozow.com/glossary/ ## Absa Pay Absa's own payment method, which the customer authorises in their Absa banking app. It gets its own button at checkout rather than sitting inside the bank list, and it requires Customer Identity Verification. See [Absa](https://www.absa.co.za/self-service/absa-pay-personal/). ## Base64 A way of writing binary data using ordinary text characters, so it can travel inside JSON or a URL. It is an encoding, not encryption: anyone can decode it. See [Wikipedia](https://en.wikipedia.org/wiki/Base64). ## Bearer token Also written: bearer authentication. An access token sent in the `Authorization` header as `Authorization: Bearer `. Anyone holding the token can use it, which is why it belongs on your server and never in a browser or a mobile app. See [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750). ## Branch code Also written: universal branch code. The six-digit number identifying a South African bank branch, the equivalent of a sort code or a routing number elsewhere. Each bank publishes one universal branch code that works for every account it holds, which is the one to use unless you have been given another. ## Capitec Pay Capitec's own payment method. The payer gives a cellphone, account or ID number rather than card details, and approves the payment in the Capitec app, so no card number and no banking login is ever entered at checkout. It gets its own button rather than sitting inside the bank list, and it requires Customer Identity Verification. See [Capitec](https://www.capitecbank.co.za/personal/transact/capitec-pay/). ## Chargeback A completed card payment reversed by the customer's bank after a successful dispute. The funds come back out, and the process runs between the banks rather than through Ozow, so it is not something you can approve or refuse. Your transaction records and delivery confirmations are what it is decided on. ## Clearing Also written: clear, cleared. Moving funds between two banks so the recipient can rely on them. It is a separate step from a payment being approved: a payment can succeed and the money still be in transit. Real-Time Clearing is the immediate version. ## Content Security Policy Also written: CSP. A response header listing the origins a page is allowed to load scripts, frames and other resources from. A policy that does not name Ozow's origin blocks an embedded checkout, and the browser reports it in the console rather than on the page. See [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP). ## CORS Also written: cross-origin resource sharing. The browser rule that decides whether JavaScript on one site may call another. It governs what a page can call directly from the browser, and it does not apply to calls made from your server. See [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). ## Customer Identity Verification Also written: identity verification. Checking that the payment instrument belongs to the natural person making the payment. Ozow requires it for merchants it has classified as high-risk, on Pay by Bank, Absa Pay, Capitec Pay, Nedbank Direct EFT, FNB Payment Requests and PayShap Request, and can disable those methods where it is not implemented correctly. ## Dispute Also written: disputed. A customer challenging a completed card payment through their own bank. A successful dispute becomes a chargeback and reverses the funds. Distinct from a refund, which you initiate and control. ## EFT Also written: electronic funds transfer, standard EFT. A transfer between two bank accounts. Used here for the standard kind, which takes one to two business days, as against Real-Time Clearing, which moves the funds immediately. A payout or refund is one or the other, and which you choose is the difference between a customer waiting minutes and waiting days. ## Float The balance held with Ozow that payouts and refunds are paid out of. Both draw on it, and neither will process while it is empty. Payins do not need one, so if you only take payments you never meet it. ## GZIP Also written: gzip compressed. A compression format. A large payload is compressed before it is sent and has to be decompressed before it can be read. See [Wikipedia](https://en.wikipedia.org/wiki/Gzip). ## HMAC Also written: hash-based message authentication code, keyed hash. A hash of a message combined with a secret key, so the result proves both that the message is unchanged and that the sender held the key. A plain hash proves only the first: anybody can compute one. This is what makes a webhook signature worth checking. See [RFC 2104](https://datatracker.ietf.org/doc/html/rfc2104). ## Idempotency Also written: idempotent, idempotently, idempotency key. A request is idempotent when sending it twice has the same effect as sending it once. It matters most where a retry after a timeout could otherwise take a payment twice. See [IETF draft](https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/). ## ISO 3166-1 alpha-2 Also written: ISO 3166, ISO 3166 Alpha-2, alpha-2 country code, two-letter country code. The two-letter country codes published by the International Organization for Standardization, such as `ZA` for South Africa and `GB` for the United Kingdom. Always uppercase. See [Wikipedia](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2). ## ISO 4217 Also written: currency code. The three-letter currency codes, such as `ZAR` for the South African rand. Always uppercase. See [Wikipedia](https://en.wikipedia.org/wiki/ISO_4217). ## ISO 8601 The international standard for writing dates and times, such as `2026-03-14T09:30:00Z`. Unambiguous about ordering and time zone, which local formats are not. See [Wikipedia](https://en.wikipedia.org/wiki/ISO_8601). ## JSON Pointer Also written: RFC 6901. A path into a JSON document, written as `/data/attributes/title`. An error response uses one to say exactly which value caused the problem. See [RFC 6901](https://datatracker.ietf.org/doc/html/rfc6901). ## JSON:API Also written: JSON API. A convention for the shape of a JSON request and response, including how errors and pagination are represented. One API follows it. See [jsonapi.org](https://jsonapi.org/format/). ## Nedbank Direct EFT Nedbank's own payment method. Like the other bank APIs it gets its own button at checkout rather than sitting inside the bank list, and it requires Customer Identity Verification. See [Nedbank](https://personal.nedbank.co.za/bank/digital-banking/needs/payments/online-shopping.html). ## OAuth 2.0 Also written: OAuth2, OpenAuth 2.0, client credentials flow, client credential flow. The authorisation framework behind the token endpoint. Ozow uses the **client credentials** flow: your server exchanges a client ID and secret for a short-lived access token, and sends that token rather than the secret on every subsequent call. See [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4). ## Pay by Bank The payer authorises the payment inside their own banking app or online banking, and the funds move from their bank account. No card is involved and no card details are entered. ## Payin Also written: payins, pay-in, pay-ins. A payment made by a consumer to a merchant. The direction most of this site is about: money coming in. Its counterpart is a payout, which sends money out and is not tied to any payment anyone made you. ## Payout Also written: payouts. Money sent from a merchant to a bank account. Unlike a refund, a payout is not tied to a payment anyone made you, so you can pay anyone with a bank account. Payouts draw on your float rather than on your incoming payments, and they are not self-service: they need approval from Ozow and testing in staging first. ## PayShap South Africa's rapid payments service, run by the banks. Low-value payments clear in seconds, and the recipient can be identified by a ShapID instead of by an account number. See [payshap.co.za](https://www.payshap.co.za/home). ## PayShap Request The request side of PayShap. Rather than the payer pushing money, the payee asks for it: the payer receives a request and approves it in their own banking app, and the funds move once they do. Enabled by Ozow on request rather than by default. See [payshap.co.za](https://www.payshap.co.za/home). ## PCI DSS Also written: Payment Card Industry Data Security Standard. The security standard that applies to anyone who stores, processes or transmits card data. Its reach is the reason most integrations avoid touching card numbers at all. See [PCI Security Standards Council](https://www.pcisecuritystandards.org/). ## POPIA Also written: Protection of Personal Information Act. South Africa's data protection law. It governs how personal information about a payer may be collected, stored and shared. See [popia.co.za](https://popia.co.za/). ## Real-Time Clearing Also written: RTC, real time clearing. Payments that clear immediately rather than waiting for a batch. A batch run settles at set times through the day; a Real-Time Clearing payment moves the funds between the two bank accounts as it is made, so the recipient can rely on them straight away. See [PayInc](https://www.payinc.co.za/services/real-time-clearing). ## Redirect Sending the payer to the Ozow payment page to complete the payment, and returning them to your site afterwards. The alternative is embedding the checkout in your own page, where the payer never leaves it. ## RFC 3339 A profile of ISO 8601 for timestamps on the internet, and what most APIs mean when they say a field is an ISO date. See [IETF](https://datatracker.ietf.org/doc/html/rfc3339). ## Settlement Also written: settlements. Ozow paying the money you have collected into your bank account. Payins arrive at Ozow first and are settled to you on a schedule, so what a customer paid you today and what has been settled to you today are different amounts. ## SHA-256 Also written: SHA256. A hashing algorithm from the same family as SHA-512, producing a shorter hash. See [Wikipedia](https://en.wikipedia.org/wiki/SHA-2). ## SHA-512 Also written: SHA512. A hashing algorithm. Ozow uses it to sign the values in a request or a notification so you can tell that they arrived unaltered and came from us. Hashing is one-way: the hash cannot be turned back into what produced it. See [Wikipedia](https://en.wikipedia.org/wiki/SHA-2). ## ShapID A proxy for a bank account: usually a mobile number, registered with the account holder's bank and used in place of an account number and branch code. Resolving a ShapID returns the account it stands for, which is what lets a payer send money to a phone number they already have. See [payshap.co.za](https://www.payshap.co.za/home). ## Site code Also written: site codes. The unique code for a site registered under a merchant. A site is a place to transact: a website, or a branch of a store. A merchant can have several, and each transaction names the one it belongs to, so sending the wrong code files the payment against the wrong place. ## TLS Also written: transport layer security. The encryption behind `https`. Every call to Ozow uses it, which is what keeps a request unreadable in transit. See [Wikipedia](https://en.wikipedia.org/wiki/Transport_Layer_Security). ## UUID Also written: GUID, universally unique identifier. A 128-bit identifier written as 36 characters, such as `497f6eca-6276-4993-bfeb-53cbbbba6f08`. Generated rather than assigned in sequence, so two systems can create identifiers without coordinating. See [Wikipedia](https://en.wikipedia.org/wiki/Universally_unique_identifier). ## Webhook Also written: notification URL. A URL of yours that Ozow calls when something happens, rather than you polling to find out. The call carries no credential of yours and arrives at a public URL, so authenticate it before acting on it: a hash field on the Payments API, a Svix signature on One API. ## ZAR Also written: South African rand, rand. The ISO 4217 code for the South African rand, and the currency every amount on this site is in unless a page says otherwise. Amounts are decimal rand rather than cents, so `100.00` is one hundred rand.