iVend Retail Extensibility Payment Processor

Agenda Overview Pre-requisite What are Payment Processors? Payment processing transaction life cycle Types of Payment Transactions Integration of Payment Processors Steps for creating a Payment Processor Implementation steps List of Payment Processors supported in iVend Artifacts Q & A

Confidential ©2016 CitiXsys. All Rights Reserved. Overview What are payment processors Transaction lifecycle of payment processing Type of payment transactions Integration with payment processor Implementation of payment processor Best practices Confidential ©2016 CitiXsys. All Rights Reserved.

Confidential ©2016 CitiXsys. All Rights Reserved. Pre-requisites A Visual Studio.NET 2010 or upper license for development .NET Framework 4.0 A DevExpress 15.2.3 license for development (optional) Contractual agreement with the third party Payment Processor provider e.g. Authorize.NET Test environment (test merchant account) for testing the developed Payment Processor Expertise with Micorosft.NET development language, tools and technologies Confidential ©2016 CitiXsys. All Rights Reserved.

What are Payment Processors? Payment Processor Allows a merchant to process (authorize  & capture) credit card transactions over networks in a secure manner Confidential ©2016 CitiXsys. All Rights Reserved.

Payment processing transaction life cycle A series of steps are involved in the life cycle of a payment processor where a  payment request is sent out through the iVend POS terminal to the issuing bank, verification and authorization at the credit card  interchange network (VISA, AMEX etc.), and a response is received back at the initiator (i.e. POS) denoting success or failure of a payment Confidential ©2016 CitiXsys. All Rights Reserved.

Authorization Steps

Confidential ©2016 CitiXsys. All Rights Reserved. Authorization Steps An initial request with the customer and card details is submitted in a secure manner to the Payment Gateway. Upon merchant account verification the request is routed to the appropriate Payment Processor  The verified Merchant Bank Processor posts the transaction for settlement in the merchant bank account against the consumer’s credit card account. The payment is simultaneously submitted to the interchange as well. The Credit Card Interchange is the link between credit card issuing banks and acquiring banks. This is the process by which the card is cleared and processed between all the entities participating in the transaction i.e. merchant bank processor, credit card issuers, etc. The processing, clearing and settlement of credit card transactions including the assessment, and collection and/or distribution of fees between parties. Interchange systems are maintained by both MasterCard and Visa. The successful transaction is then transferred to the credit card issuing bank that verifies fund availability in the customer\’s credit card account. The results are sent back through. Confidential ©2016 CitiXsys. All Rights Reserved.

Confidential ©2016 CitiXsys. All Rights Reserved. Authorization Steps The credit card issuing bank passes the approved transaction results back to the Credit Card Interchange network. The credit card interchange relays the transaction results to the Merchant Bank’s Processor.  The Merchant Bank’s Processor relays the transaction results back to the payment gateway.  A preformatted response is sent back by the Payment Gateway to the POS terminal i.e. the merchant. Transaction results are stored and displayed to the consumer. The approved transaction amount is deposited by the Credit Card Interchange in the merchant’s bank account. Confidential ©2016 CitiXsys. All Rights Reserved.

Types of Payment Transactions (supported by iVend Retail) Card Present Transactions Consumer must present a physical credit card when making payments for goods The POS terminal captures the card data from the card including card number, expiration date and counterfeit detection value to the Card Issuer for authorization Card data can be captured manually i.e. keyed in or electronically i.e. from authorized card readers (Magnetic Stripe Readers) Additionally PIN Pads are supported at POS terminal for PIN debit using PCI PTS (Pin Transaction Security) compliant hardware. Card Not Present Transactions A face-to-face contact with the Cardholder is not required. Mail Orders (MO), Telephone Orders (TO) and Electronic Commerce (EC) transactions are typical examples Two verification processes are used for these transactions Card authorization using Cardholder billing address (AVS) Card authentication using Card Verification Value 2 (CVV2 / CVC2 / CID) Confidential ©2016 CitiXsys. All Rights Reserved.

Integration of Payment Processors in iVend Retail iVend Retail is completely written in Microsoft .NET The Payment Processor integration design and implementation is modular. Formal tie-ups with multiple Payment Gateways / Processors.  22+ processors integrated. Each Processor has its own API (Application Programming Interface) Processors based on universal payment processing standards. Differ primarily on ‘Request-Response’ payload structure. Authentication and Authorization processes are similar across all processors. The order and number of parameters may differ. It is possible to add a new payment processor. However, these are based on a set of specifications. Payment processor written for TPOS does not work for mobile POS (mPOS) Confidential ©2016 CitiXsys. All Rights Reserved.

Steps for creating a Payment Processor

Steps for creating a Payment Processor Create a new project in Visual Studio 2010 (with SP1). Ensure that the Assembly Name and the Default Namespace starts with ‘CXS.Payments.<ProviderName>’ where <ProviderName> is the actual name of the provider e.g. AuthorizeDotNet. Make sure that the settings of the project is similar to the details shown in the sample illustration below continued………. Confidential ©2016 CitiXsys. All Rights Reserved.

Steps for creating a Payment Processor Add references to the following iVend Retail libraries , DevExpress libraries and system libraries continued………. Confidential ©2016 CitiXsys. All Rights Reserved.

Steps for creating a Payment Processor Add class named AuthorizeDotNetPaymentSystem.cs’ and include following CXS namespaces using CXS.Payments.Core; using CXS.Platform.Globalization; using CXS.Platform.Runtime; using CXS.Platform.Xml; Inherit the interface ‘IPaymentSystem’ and implement the interface. Add your custom implementation logic to the interface members continued………. Confidential ©2016 CitiXsys. All Rights Reserved.

Steps for creating a Payment Processor Add the ‘ConfigInfo.cs’ class (provided in sample) into the project and change the namespace appropriately. This class is to keep and set required properties for the processor being implemented. (Note: The properties are defined on the basis of specifications given by the provider of the payment processor e.g. AuthorizeDotNet) Confidential ©2016 CitiXsys. All Rights Reserved.

Steps for creating a Payment Processor Add an XML file named ‘CXSPaymentsAuthorizeDotNet.global.xml’ file in your project. Ensure that the XML file is included as an embedded resource as shown below. This file is used to keep the properties related to user interface element and error information for the specific provider The naming convention of the XML file is: ‘<ClassName>.global.xml’ where the class name is the name of the only implementation class in the project that inherits the ‘IPaymentSystem’ interface. For the sake of this example, class is named ‘AuthorizeDotNetPaymentSystem’ and hence the name of this XML file is ‘AuthorizeDotNetPaymentSystem.global.xml’ Under the root element/node ‘String’ there are only two header level elements as shown below: The ‘SetupControl’ element is a predefined/fixed name while the element i.e. ‘AuthorizeDotNetPaymentSystem’ is named exactly as the actual implementation class continued………. Confidential ©2016 CitiXsys. All Rights Reserved.

Steps for creating a Payment Processor Child elements under the ‘SetupControl’ element refer to the properties of the user control in the project representing the user interface elements. For example, assuming that the user control has the following fields defined: The corresponding elements and their values in the ‘SetupControl’ node would be: Confidential ©2016 CitiXsys. All Rights Reserved.

Steps for creating a Payment Processor Child elements under the ‘AuthorizeDotNetPaymentSystem’ element contain the error information for the specific provider. For the sample processor, the sub-elements and their values are: One should change the element names and their values as appropriate when adding your own payment processor continued………. Confidential ©2016 CitiXsys. All Rights Reserved.

Steps for creating a Payment Processor The iVend Retail product embeds the graphical elements of each payment processor individually. This means that every payment processor must create the user interface part as well along with the code logic of the payment processor. This control is known throughout the product as ‘SetupControl’ that uses the ‘XtraVerticalGrid’ control of the DevExpress Suite for building the user interface To build a user interface for the new payment processor include the sample  ‘SetupControl.cs’ file and ensure that it inherits from the ‘BasePaymentsSetupView’ class and the ‘IGlobalizeControl’ interface. Add program initialization routines in the constructor and override the ‘SetupView’ method to bind the grid to the data source. Call the ‘FireDone’ method in the ‘OkButtonClickHandler’ event to raise and bind the event Confidential ©2016 CitiXsys. All Rights Reserved.

Steps for creating a Payment Processor Create a sample test project (as provided in sample ) to configure and test the developed processor with the ‘Test Merchant Account’. Add an XML file named ‘ProcessorConfig.xml’ and change the configuration element values in the file as shown below: Confidential ©2016 CitiXsys. All Rights Reserved.

Steps for creating a Payment Processor Execute the test project to bring up the ‘Test Project’ form. Enter valid card details, transaction amount and select appropriate ‘Transaction Type’ options to test each transaction type Select the ‘Debit Card’ tab and re-enter valid values when testing for a debit card type processor. Verify the results using the administration console of the test account and ensure that the transactions are PA- DSS compliant. Confidential ©2016 CitiXsys. All Rights Reserved.

Implementation of Payment Processor

Implementation of Payment Processor Deploy and configure the tested processor in iVend Retail using Management Console. Open the setup screen by clicking on the ‘Payment Processor’ menu Confidential ©2016 CitiXsys. All Rights Reserved.

Implementation of Payment Processor Ensure that the assembly for the processor is copied in the ‘Install’ location of iVend Retail. Browse and select the location of the tested assembly by clicking on the ellipsis (…) Confidential ©2016 CitiXsys. All Rights Reserved.

Implementation of Payment Processor Select the class name from the drop down Click on the ‘OK’ button to complete the processor setup. Restart all iVend applications for the new processor to load and activate the configured processor. Confidential ©2016 CitiXsys. All Rights Reserved.

List of Payment Processors supported in iVend S No. Processor Region 1 ATOS Worldline Belgium 2 Authorize.net USA 3 BS Cards Germany 4 Cayan (Genius) 5 Commidea UK 6 Credomatic Mexico 7 DataCap 8 DPS Australia, New Zealand 9 Ficosha 10 FirstData 11 GlobalPay 12 Heartland US 13 Mercury 14 Moneris eSELECTplus Canada 15 Paymentech 16 PayPal Payflow Pro 17 PC-EFTPOS Australia 18 Plutus India 19 TransFirst 20 TSYS 21 WorldPay 22 YesPay Confidential ©2016 CitiXsys. All Rights Reserved.

Best Practices

Confidential ©2016 CitiXsys. All Rights Reserved. Best Practices iVend is PA-DSS certified. Ensure that you meet the minimum guidelines for adding a custom Payment Processor Do not retain full magnetic stripe, card validation, code or value, or PIN block data Protect stored cardholder data Provide secure authentication features Log payment application activity Develop secure payment applications Protect wireless transmissions Test payment applications to address vulnerabilities Maintain instructional documentation and training programs for customers, resellers, and integrators Confidential ©2016 CitiXsys. All Rights Reserved.

Confidential ©2016 CitiXsys. All Rights Reserved. Best Practices Facilitate secure network implementation Cardholder data must never be stored on a server connected to the internet Facilitate secure remote software updates Facilitate secure remote access to payment application Encrypt sensitive traffic over public networks Encrypt all non-console administrative access Confidential ©2016 CitiXsys. All Rights Reserved.

Artifacts

Confidential ©2016 CitiXsys. All Rights Reserved. Artifacts Citixsys Knowledge Portal https://knowledge.citixsys.com/knowledge-base/-/knowledge_base/article/60118 Sample Projects: sample code.rar Confidential ©2016 CitiXsys. All Rights Reserved.

Question & Answers