Authorisation/Debit with 3DS 2 Data * ** Merchants have the choice of doing 3D secure authentication directly with the 3DS Vendor ("MPI")  or via the   iVeri Gateway.  [1]  In any event, when the authentication process is completed successfully, the merchant can POST the payment instruction to the iVeri Gateway with the authentication data using the   SOAP [2]   or   REST [3]   webservice. Debit/Authorisation Payment Parameters * The applicable set of 3DS 2 parameters are expected in the Authorisation/Debit message are as follows Parameter * Description *     CardHolderAuthenticationID Mandatory for 3DS 1 and 2: Commonly known as an XID:  * Unique identifier generated during the 3D secure process CardHolderAuthenticationData Mandatory for 3DS 1 and 2:  * Commonly know

MIT - Recurring & MOTO * ** First Transaction * When performing your first transaction using application id: 00000000-263b-4315-b2cd-000000000000, the gateway will return the TransactionIndex, masked PAN and Expiry Date, which you will need to store in your database. Debit with PAN * Process a COF transactions by setting CardholderPrense to “MOTO, Recurring ” and providing the full card details. CardholderPresence": "MOTO, Recurring” PAN:   ExpiryDate: Debit with TransactionIndex  * Process a Recurring transactions by setting the PANFormat and “Sanitised/tokenised card details. PANFormat  PAN:   ExpiryDate:  TransactionIndex The following field response values need to be stored on your database, linked to the card holder details. TransactionIndex PAN ExpiryDate Subsequent - Recurring Trans

Specialized Techniques * ** Ping * The Ping command is primarily used to determine if the connection between the Merchant and the Acquirer is down. If the connection is down, then a Ping can be used to poll the iVeri Gateway to see when the status is back up. The Ping command checks that: the merchant is communicating with the iVeri Gateway, and the merchant configuration is active, and the iVeri Gateway is online, and the iVeri Gateway is communicating with the acquirer. This is different to checking network connectivity to the iVeri Gateway, where a network ping should be employed. The Ping takes an ApplicationID as a mandatory input parameter and is sometimes referred to as an ApplicationID Ping. As mentioned previously, an iVeri transaction involves communication between the following

Track2 encryption via Master/Session encryption * ** A POS Device Integration architect has the option sending the Track2 to the iVeri Gateway in an encrypted format. This optional functionality is there as an extra security measure against someone sniffing the data between the device and the server communicating with the iVeri Gateway. The Master/Session Track2 encryption process flow is the following: A Device (with a DeviceSerialNumber and a DeviceMake) is injected in a Trusted Centre with a Track2 Master Key. A merchant periodically sends a request for a session key (getTrack2SessionKey) which is returned encrypted under the Track2 Master Key. When performing a transaction or a balance enquiry, the Track2 is sent encrypted using the current Track2 session key. Track2 Key Injection for

Pre-Auth Completion – Follow-up Debit ** Allows the merchant to instruct the cardholders bank to release and debit the funds previously reserved or pre-authorized REST SOAP Request { "Version" :  "2.0" , "CertificateID" :  "{5c4b9c74-0063-4240-9cff-f730675c5bd0}" , "ProductType" :  "Enterprise" , "ProductVersion" :  "WebAPI" , "Direction" :  "Request" , "Transaction" : { "ApplicationID" :  "{d8d5a94-8fa0-428d-a539-3a5baf166f7f}" , "Command" :  "Debit" , "Mode" :  "Test" , "Amount" :  "1000" , "MerchantTrace" : "20220812_1044" , "TransactionIndex" :  "{5C8F61BE-15AD-4201-B361-66AD52D2EFAE}" } } < soap:Envelope   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd = "http://www.w3.org/2001/XMLSchema"   xmlns:soap = "http://schemas.xmlsoap.org/soap/envelope/"> < soap:Body > < Ex

Fleet card transactions ** Fleet cards facilitate the tracking of costs and managing statistical information of a fleet of vehicles. A Fleet transaction refer to special processing for a Fleet card.  Fleet transactions are currently only available within distributor Nedbank.  If a fleet card is received with other distributors, then the fleet specific parameters are ignored.  Coding for Fleetcards  * The following optional input parameters are Fleet specific per transaction: CustomerReferenceIdentifier The following optional input parameters are Fleet specific per Line item: ProductCode  Quantity  QuantityDecimalPlaces  UnitCost The latest available values of the ProductCode field are obtained via the “Inventory” download command (See section 22). Only use the ProductCodes with Type='Fle

PosPort -Transactions – View – Transaction History ** / Purpose: /* Users can access the Transaction History feature, enabling them to select a date range and view transactions spanning up to 6 months in the past. To access the Transaction History from the dashboard or homepage, users will navigate to the menu, then select the PosPort dropdown. Next, they'll click on the Transactions dropdown, followed by clicking on the View dropdown, and finally select Transaction History. Select the application mode the user would like to View Transaction History for. The user will now be able to select the date for transaction history they would like to view. Transaction details for the last 6 months will be available for the user to view. The transaction history and details thereof will be displayed f

V4.144 10/05/2024 ** The release notes provided in V1 of this document serve as an initial preview of the changes expected in the production release scheduled on May 19th, 2024, on the Hosted Gateway. Summary* The Gateway release notes will contain information related to the new iVeri software release. The release notes will include the impact of software release to the intended target audience. The release notes will adopt the format outlined below, as applicable:* Compliance* - Refers to the adherence of the software to specific industry standards, regulations, or internal policies. This includes ensuring that the software meets legal and regulatory requirements, follows best practices, and aligns with established security and quality Optimisation* - The process of refining or improving

Checklist – Cardinal & Admin Website Quality Check ** What to check * How to Check it * * 1. Check Profile Creation * Check if the profile is completed accurately. Go to Merchant Profile >> Update >> General. * 2. Check Billing * Check if charges are applied properly based on what has been agreed, (i.e. net settlement or EFT etc). Merchant Profile >> Update >> Parameters . * 3. BackOffice Services Update * Check if all the Service updates are done for Merchant Admin, Cardinal and iVeri Backoffice . Go to Merchant Profile >> Update >> Back Office Services . * * 4. Cardinal Authentication method * Check if the merchant has been properly created in cardinal to create the link between IYS and Cardinal for iVeri to be the Payment Provider. Go to Cardinal Admin >> Merchant Login >> Login in as

UPOP SecurePlus Parameters * * Parameter Node Type Data Type Min Length Max Length Description UPOP_TransactionTime tag String The time when the Merchant sends the transaction. Date and time formatted as an ISO 8601 combined date and time string using the extended format. - Format: YYYY-MM-DDThh:mm:ssZ - YYYY = year - MM = month - DD = day - hh = hour - mm = minutes - ss = seconds UPOP_RelatedTransactionType tag String 2 2 Related Transaction Type. One of: - Purchase - Pre-authorization The corresponding UnionPay protocol values are: - 01: Purchase - 02: Pre-authorization UPOP_RequestID Tag Guid 38 The RequestID that was returned as part of the Request Creation that will be used to retrieve data for the Authentication Validation UPOP_FrontUrl Tag URL 256 UPOP send the transaction result no