Verifone ICP Payment Gateway (V3 & 4) Installation and Configuration Information

Transcription

1 Verifone ICP Payment Gateway (V3 & 4) Installation and Configuration Information Flint Technology Ltd +44 (0)

2 Table of Contents Table of Contents... 2 Installation Instructions... 3 Support Contact... 3 Configuration & Operation... 4 Card Checkout Front End... 4 Gateway Configuration... 5 Card Checkout Configuration... 6 Mail Order & Telephone Order (MOTO) Configuration... 7 Saved Card Configuration D Secure Check Font end screenshot... 9 Customer Saved Card (token) D Secure Configuration Frequently Asked Questions How Tokens Are Used Customer Facing Messages Integrating With External Systems Common Questions

3 Installation Instructions Flint Technology has produced a module to allow Magento to be integrated with the Verifone ICP V4 Payment Gateway. Flint can provide full installation, but should developers wish to undertake this themselves then they should take the following steps: Disable Magento compilation function Place the zip/tar file on the server Unpack and copy the files into the root of the Magento installation Verify the module is in place in the Magento back office screens If the installation is not showing then clear the cache Re-enable the Magento compilation functionality Support Contact If further information is required, please contact our support team on +44 (0) info@flinttechnology.co.uk 3

4 Configuration & Operation Once the module is installed it will be configurable under System>Configuration>Payment Methods> The below screenshots will be displayed. Card Checkout Front End Displays as a normal Magento payment gateway module. Also compatible with the OneStep checkout module. Save card functionality is also available. 4

5 Gateway Configuration Configurable on a store by store basis. Full logging facilities. 5

6 Card Checkout Configuration Configurable AVS & 3D Secure settings Supports Auth Only or Auth & Settle transactions 6

7 Mail Order & Telephone Order (MOTO) Configuration 7

8 Saved Card Configuration 8

9 3D Secure Check Font end screenshot 9

10 Customer Saved Card (token) 10

11 3D Secure Configuration 11

12 Frequently Asked Questions 1. How Tokens Are Used All transactions with Commidea are made using tokens, except the initial token registration transaction (without which a token cannot be obtained). All tokens are saved by the system - card numbers are never saved. The "save card for later" feature of the module is a front end facility for users to encourage loyalty and permit faster checkouts on subsequent orders. This feature has no effect whatsover on the use of tokens for storage and communicating with Commidea behind the scenes, and indeed is only possible (safely) because the system is handling tokens and not cards. All tokens are stored regardless of whether the customer engages the "save card for later" feature or not. Issued tokens can be reviewed via Magento admin screens (menu "Sales/Commidea ICP XML V4/Issued Tokens"). 2. Customer Facing Messages Customer facing messages, presented to the user during the checkout process, are critical to passing Commidea's integration testing process, and are overwhelmingly the cause of integration failures and delay. These messages are managed via the file "app/locale/en_gb/flint_commidea4.csv" (or "app/locale/en_us/flint_commidea4.csv", depending on your store's locale). By default the module provides informative debugging messages to assist with initial testing and experimentation. Prior to undertaking an integration test with Commidea, these messages must be changed to be more user friendly. The module therefore provides the file "app/locale/en_gb/flint_commidea4.csv.sample-live" containing examples of customer facing messages, whose content can be moved into the Flint_Commidea4.csv file prior to integration testing. Unfortunately Commidea do not publish an authoritative list of accepted customer facing messages, and therefore we cannot confirm that the sample messages are sufficient to pass your integration tests, however they will give you an indication of what's required and a head start. If you encounter an integration failure due to a message, we would be most grateful if you would advise us (support@flinttechnology.co.uk) so we can improve the module's 12

13 sample messaging. 3. Integrating With External Systems Many Magento implementations integrate with external accounting, logistics or warehousing solutions, and these often require payment information be transferred from Magento to these systems - usually for deferred settlement. The module provides an easy point of integration for these solutions (for developers) via the event "flint_commidea4_payment_complete", which is invoked once payment details have been successfully processed for an order. All information pertaining to the successful Commidea payment transaction is exposed via this event, right down to the actual xml response from the gateway itself. Commonly required information can be extracted as follows: i) The transaction amount: $event->getpayment()->getcommidea4transactionamount() ii) The token id: $event->getpayment()->getcommidea4token() iii) The transaction id: $event->getmessages()->gettransaction()->gettransactionid() iv) Raw gateway xml response for token details: $event->getmessages()->gettoken() ->getresponse()->getsoapresponse()->processmsgresult->msgdata->... v) Raw gateway xml response for transaction details: $event->getmessages()->gettransaction() ->getresponse()->getsoapresponse()->processmsgresult->msgdata->... vi) Raw gateway xml response for authentication details: $event->getmessages()->getauthentication() ->getresponse()->getsoapresponse()->processmsgresult->msgdata->... Note that getmesages() exposes the actual transaction interactions with the Commidea gateway, and therefore not all message objects are always available within this event. Some are configuration dependent (authentication objects are only available if you have enabled 3D secure checks), and others may be process dependent (a token message object may not exist because the token registration transation was not conducted - perhaps because the token was 13

14 registered and saved weeks ago). You should therefore always code defensively to ensure these objects exist before referencing them. Note also that most of this data is not persisted in order to minimise PCI requirements (for example PCI does not permit saving of card CVC codes). An integrator would typically extract the integration data required during this event, and use it to: a) annotate other objects which may be subsequently exported to an external system b) write selected data into the payment object, and save permanently to the database (and understanding the PCI implications) c) perform the export of this information during the event itself A sample file "app/code/community/flint/commidea4/model/integration/mnp.php" illustrates how to extract payment information during this event, but is not intended to demonstrate a complete integration solution. 4. Common Questions These questions are typically asked by Commidea during the testing process. Q. Can you confirm the processingdb is not hard coded? A. Yes, we can confirm this. The module has passed testing multiple times and operates in production environments. However we cannot easily prove this - only Commidea can prove this by supplying the module with different processingdb values and confirming that these are correctly processed. 14