This document uses certain iVeri specific terminology which can be referenced in Parameter Description

Out of Band Transaction notification is a dedicated messaging system that allows merchants to receive their transaction outcome reliable and timeously. The transaction outcome available in the Out of Band notification system contains the same data elements as would be found when doing a transaction look up in the gateway's endpoint or directly from Backoffice. Merchant developers can implement a webservice that will consume the transaction notification payload. The transaction notifications are usually available when the cardholder completes a payment to the merchant. Format of the OOB Transaction Notification The transaction notifications to the merchant are JSON formatted, the body of the message contains a Base64 string of the VXML response. The VXML response parameters are defined in

The examples apply when using the web service interface to perform various transactions. The examples serve to showcase a set of parameters that are largely used when performing transactions using the schema definition available in the SOAP interface which are also commonly used on the REST API. The functionality and related parameter definitions, elements supported are standard in the SOAP [1] schema and REST API [2] Further insights on the transaction types and their meanings, refer to the “ Commands [3] ” and “ Actions [4] ” sections and these have to be used in conjunction with the input parameters per actions. For the corresponding transaction flows per transactions type refer to transaction sequence The examples cover the following messages: The transaction Request and Response cover

Additional Data for Procurement Transactions ** Procurement transactions refer to transactions that contain the line item (or order basket) details. If the line-item details are sent to iVeri within a transaction, then a procurement card holder get those details from their issuing bank (for example on their monthly statement). This is of assistance in tracking business to business transactions particularly in large corporations. Procurement transactions are currently only available within distributor Nedbank. Coding for Procurement * The following optional input parameters are Procurement specific per transaction: CustomerReferenceIdentifier  CustomerVATRegistrationNumber  DestinationCountry  DestinationZIPCode  NationalTax  NationalTaxIndicator  OrderDate  PurchaseIdentifier  ShipFromZIPC

A service that enables payment card cardholders to make international card purchases or transactions in their own currency. The conversion of the purchase price of goods or services from the merchant’s local currency to the cardholder’s home currency occurs at the point of sale at the quoted exchange rate from a cited exchange rate source. PAYD* PayD transactions allow the customer to make a payment using their debit card + pin, without a POS device present (i.e. web site purchases), by using their mobile phones PayD Process* Customer selects payD as payment method for the transaction. (The payment selection process is provided by the merchant) Customer enters their mobile number instead of their card details. (Card details are not present in the V_XML) PanFormat is set to MSISDN and the

Merchants are required to enter into a “Agreement” with an authorized Acquiring Institution. Once there is a merchant agreement in place, a merchant profile can be created. With Enterprise calls to the Gateway, the presence of a certificate ID is required, with the actual physical certificate available as optional means to authenticate merchant requests.  Test Mode should be used during integration, testing, and validation. Test application ID must be used with Mode Test

A Payment Facilitator (PAYFac) serves as a specialized payment service provider that collaborates closely with an acquiring bank. Its primary role involves constructing robust systems for handling payment transactions, facilitating the onboarding of sub-merchants, and managing risk factors. Once the PAYFac has established systems and processes, which adhere to the guidelines set forth by card networks and align with the acquiring bank’s agreement, it can seamlessly offer comprehensive payment processing solutions to merchants. These merchants, commonly referred to as “sub-merchants,” benefit from the streamlined services provided by the PAYFac model. Notably, in this model, sub-merchants are relieved of the direct interaction with an acquiring bank, simplifying their payment processing exp

VISA CheckOut  ** Visa Check-Out is a digital representation of a cardholders Visa Card. Cardholders can register their debit or credit cards by downloading the Visa Check-Out app. Once cardholders have their profiles and card details loaded in Visa Check-out, they are able to make purchases at merchants who are accepting Visa Check-Out payments. Illustration of Visa Check Out with Enterprise* VISA%20Check%20out [1] Process Flow in Visa Check-Out with enterprise* Cardholder selects Visa Check-Out as payment method Enterprise Merchant calls Visa Light Box or Widget and presents it to the Cardholder to Login Cardholder Logins via Visa Light Box    Cardholder selects a card and presses Continue Upon clicking Continue, Enterprise Merchant sends the Call ID to the iVeri gateway The iVeri gat

This purpose of this sections is to give some domain knowledge to people not familiar with the payment domain. Card Present vs. Card Not Present ***   A Merchant interfaces with a card holder and submits a Card Present Transaction request whilst the card holder is waiting, and the card holder authenticates the transaction (typically via signature or PIN entry). In the event of a dispute of the transaction, the merchant must prove that the card holder authorized it, else merchant is liable to refund the card holder. A Merchant submits a Card Not Present Transaction according to previously arranged agreement with a card holder. The card holder is not present to authenticate the transaction. In the event of a dispute on the transaction, the merchant must prove the card holder authorized it, e

Transaction Result Codes ** Result Status * Result Code * Result Description * Only relevant when * 0 (OK) 0 N/A (Approved) -1 (Not OK) 1 Timeout waiting for response -1 (Not OK) 2 Gateway unreachable -1 (Not OK) 3 Hot card -1 (Not OK) 4 Denied -1 (Not OK) 5 Please call -1 (Not OK) 6 Card Address failure 1 (Warning) 6 Warning: Approved but Card Address failure -1 (Not OK) 7 Card Security Code failure 1 (Warning) 7 Warning: Approved but Card Security Code failure -1 (Not OK) 8 Card Type not accepted -1 (Not OK) 9 Unable to process the transaction -1 (Not OK) 10 Card blocked -1 (Not OK) 11 Invalid amount -1 (Not OK) 12 Invalid budget period -1 (Not OK) 13 Void unsuccessful Command Void -1 (Not OK) 14 Invalid card number -1 (Not OK) 15 Invalid track2 -1 (Not OK) 16 Invalid card date (Expiry D