3D secure 2 is the latest standard released by EMVCo that allows merchants and payment service providers to send additional data elements to the issuing bank of the cardholder, which in turn, makes it possible for the issuer of the card to perform frictionless authentication and offer an improved, better, user experience to the cardholder. With the additional data elements relating to the cardholder, issuers can apply Frictionless Authentication flows or “Challenged” authentication flows. Frictionless Authentication Flows: * issuers can apply risk-based decisions using the additional data received and trust that the real cardholder is making the purchase and auto authenticate the transaction in the background without requesting any additional information from the cardholder. Challenged Aut

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

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 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

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

The following section covers the details of POS Device integration (particularly PIN based transactions). PIN transactions are encrypted either using Triple DES DUKPT or Triple DES Master/Session encryption architecture. The combination of Acquirer and type of device used determine the encryption architecture chosen. iVeri provides facilities where PIN transactions can be process in either mode Live or Test.For security reasons, a key cannot be used in both modes Live and Test. Therefore, a device is either loaded for mode Test or mode Live. A Device that is to be used for mode Live must be injected with a key within an iVeri Trusted Centre using the appropriate encryption architecture.A Device that is to be used for mode Test may be injected by a merchant, or within the Trusted https://ce