* Purpose - * To set the Security Parameters for all users in terms of their passwords, validity, suspension, and login notifications. These parameters can only be set by the Back Office Administrator. * Action:  * In the menu bar, click on User Manager, scroll to, and click on Security Configuration. This will bring up the following form on which you can now change the system defaults to suit your own requirements. Please remember that changes made to the defaults will apply to ALL users that you have given BackOffice access to */ Note: /* Strong Password: The default is No. This means that the password can be anything if it is not less than the default minimum length. If you change the default to Yes, then the user’s password must be a combination of alpha/numeric and special characters

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

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 schema and REST API Further insights on the transaction types and their meanings, refer to the “Commands” and “Actions” 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 the following: 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 Merchant Take-On  * Merchants can also register for Visa Checkout to start accepting e-wallet payments from cardholders. To register merchants can mouse to the “Transaction Viewing Layout” section click on the “Reset Transaction Viewing layout dropdown, select “Visa Checkout Management” click the “Submit” button. A new page will be display and the merchant can be populating all the fields displayed on the below screen and Submit. NB: The merchant will also need to notify the Acquiring bank that they need to be enabled for Visa Checkout.

Airline Data ** Parameter Node Type Data Type Min Length Max Length Description PassengerName subTag AN 0 60 Passenger's first name. PrimaryTicketNumber subTag AN 0 60 FirstDepartureLocationCode subTag AN 0 32 FirstArrivalLocationCode subTag AN 0 32 OfficeIATANumber subTag AN 0 32 OrderNumber PlaceOfIssue DepartureDate Note: The fields in Blue will only be used when doing CyberSource Advanced Fraud Screening. CompleteRoute DepartureTime JourneyType

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

AuthenticatedCollectionData Parameters * * Parameter Node Type Data Type Required/Optinal Max Length Description AccountNumber subTag AN R 19 The account number that the payor is agreeing to allow the payee debit. DebtorIdentification SubTag AN R 35 Some data to identify the payor e.g., ID Number DebtorIdentification subTag AN R 12 The maximum amount that the payor is agreeing to in the smallest unit of the currency specified (eg in cents)

View * **

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