Home

IPG Manual - IIS Windows Server

1. Property Usage Comments Request Properties Customer Customer ID Please refer to section 5 3 3 for MANDATORY Customer details Store Store Please refer to section 5 3 3 for Store details OPTIONAL Terminal Terminal Please refer to section 5 3 3 for Terminal OPTIONAL details IPG Features Document Merchant Integration Support 51 ula etisalat Channel Payment Channel Please refer to section 5 3 3 for MANDATORY Channel details TransactionID TransactionID returned in SPI Registration call MANDATORY Response Properties OrderlD It s returned only in case of successful transaction and if it had been set during Registration call for same ApprovalCode ApprovalCode as sent by the issuer bank Merchant should save this code for future reference and communication with issuer bank related to a particular transaction Amount Amount charged for the transaction Balance Balance amount for the transaction that has not yet been captured CardNumber Masked credit card number in following format EFE OX It will return first 6 and last 4 digits of credit card used for payment CardToken Tokenized value for the card used it s not original credit card number but will always be same for any particular credit card number Account Name of account in payment gateway configurations that transaction happened with to avoid any confusions use this field for any refe
2. Issues e Transaction faced error at any stage in transaction life cycle and got failed Comments Incase anything is confusing still getting any issues while making Registration call please contact merchant integration etisalat ae Merchant Integration Support IPG Features Document Merchant Integration Support 72
3. ala etisalat Integrated Payment Gateway Manual Document Merchant Integration Support Version 2 0 Prepared by Merchant Integration Team Email merchant integration etisalat ae Updated June 2015 cd lail etisalat Table of Contents IMPORTANT CONTACTS Srini genee Raae aE e ege nit aid 6 COmtrUStSUPpoOt lA Mii ts 6 PRUSUDDO sa eo eatin ed tiara 6 Operations ani as 6 Merchant Integration Support 7 AM 3 DM 6 A INTRODUCTION conri ias H NR Ee te EC 8 V2 Glossary Ori Stn EE 8 2 TRANSACTION TY PES soii a dis 13 2 1 Pointof Sale POS E 14 2 2 Web BaseO RE EC 14 2 3 Mail Order Telephone Order MOTO 15 2 4 Cardholder Activated Terminal CAT 15 2 5 RECUPFING Payments css asacedeceseceaeccadscbatsadacadeasededecsseacagecadanbeasadacatecsudeReonadetae 16 2 6 BizDirect Direct Debit Payments ooococnnnccccnnonooccnnononncnnnnonnnnnonononnnononnnnnnnn cnn nnnnn cnn nana nn nnnnannnnnnns 16 2 7 Any Device Capable to Integrate Sbt nn ncrannnnncnnns 16 Se PAYMENT MODELS ege eege eene eege eege Eege eege 17 3 1 Authorization Model zsinatra aaar ae a a aE AE aR AR ds 18 3 1 1 Card Not Present Card Not Present Scenario 18 Intro dUCtiON E 18 IMplementat Nc A A A Eege 19 SLIM Ee Captlt ranian is a at sade eee 19 3 1 1 2 ER O 19 A OS 21 3 1 2 Card Present Card Present Scenario 21 le n EE 21 Implementation EE 21 3 1 21 AUTO Caplio da ini ales 21 IPG Features Document M
4. cv lail etisalat 3 PAYMENT MODELS IPG provides two models for making electronic payments depending on presence of payment instrument i e Visa Card etc 1 Authorization Model Authorization Model refers to the traditional way for making online payments where Merchant seller collects all the credit card related information from his Customer buyer and sends it to the Payment Gateway for processing This model is also adapted for payments where redirection is not an option like POS terminals CAT transactions MOTO transactions and other SPI enabled devices 2 Redirection Model Redirection Model is a more secure way considered for online payments where Merchant seller redirects his Customer buyer to Payment Gateway provided page exposed on Payment Gateway network buyer provides his credit card related information to Payment Gateway directly and is redirected to seller website after authentication and other checks by Payment Gateway This model is secure as credit card data is not handed over to any untrusted party according to PCI standards any non PCI compliant party cannot save credit card information 3 3D Secure In compliance with 3D Secure security guidelines IPG provides a common payment portal which can be used by the merchant for redirecting the card holder once he is ready to provide the credit card details The information is then taken by IPG through the Merchant Plug in and passed to the Issuer for Auth
5. etisalat OrderInfo Details of order OPTIONAL TransactionHint It is used to specify which payment instruments OPTIONAL should be available to the buyer Merchant can specify which features should be supported by payment instrument i e Auto Capture Reversal or Manual Capture Reversal By default it is set Auto Capture please refer to section 5 3 4 Transaction Properties for details Recurrence Type Marks a transaction for registering Recurring MANDATORY for Payments registering Recurring Payment Response Properties TransactionID Reference for ongoing transaction to be used in all SPI calls made for this transaction TransactionID should be saved by Merchant for any future references to a particular transaction in IPG system PaymentPortal Link to IPG Common Payment Page CPP where payer has to be redirected for providing Credit Card information for next step in completing the transaction 5 2 2 Finalization Once payer has been redirected back to Merchant website ReturnPath provided in Registration from CPP after providing Credit Card information Merchant has to send SPI Finalization call to actually block the money from payer s card in case of Manual Capture and to complete the transaction in case of Auto Capture Following is the list of properties applicable for SPI Finalization call this list does not include configuration properties settings mentioned in sub sections of 5 1
6. 5 3 5 Buyer Properties Property Description CardNumber Credit Card number ExpiryYear ExpiryMonth as mm and ExpiryYear as yyyy ExpiryMonth VerifyCode This property refers to CVV2 CVC etc The format of the value has to match format used by given card brand 3 digits for Visa MC JCB and Diners and 4 digits for AMEX and Simulator Some brands accept to additional symbols N A to indicate that VerifyCode is unavailable and ILG which specifies that the value printed on the card is illegible CardTrack2 This property is used in case of card present scenario where payer swaps the card into a machine like KIOSK KIOSK reads the Card Track 2 Data and sends it to IPG in CardTrack2 field Note In caseCardTrack2 is being sent to IPG then there is no need to send any other property from Buyer Related Properties 5 3 6 Response Properties These response properties can be retrieved in response to a particular call For code sample syntax refer to Section 5 3 8 2 Late Bound Properties Property Description ResponseCode This field returns the exact response code Success is always indicated with 0 and any code using SPI component should verify this status Note The exact meaning of this value may be different depend on the buyer s card issuer merchant s account bank or the step at which authentication failed which means that we are unable to provide a list of all possible descriptions in ord
7. CPT Y along with other property has a value CPT N along with other separated values separated values Requires no extra call or interaction Requires to manually initiate a capture reversal call may or may not involve user interaction depending on business requirements IPG Features Document Merchant Integration Support 33 ula etisalat Full amount mentioned to be paid will In this case SPI Finalization will get the automatically be captured instantly after response back only blocking the amount blocking without any control to stop this action Capture seems to be a part of SPI Finalization call Allows to only capture full amount Allows both SPI Capture and SPI Reversal automatically in one go calls If no amount and currency has been mentioned it processes full amount available as blocked amount which is a default behavior If specific amount and currency has been provided for capture or reversal only mentioned amount is processed provided that it does not exceed amount available as blocked This is called Partial Capture Reversal Only single capture request Multiple capture reversal calls can be sent at different times before all blocked amount is captured reversed SPI Finalization call closes the transaction Transaction is not closed at SPI Finalization itself instead it s closed when full amount has been captured or reversed Auto Capture is recommended if your If bus
8. Card Brand IPG IPG Features Document Merchant Integration Support 65 un lail etisalat 7 FAQs AND KNOWLEDGEBASE In response to any call posted to IPG through SPI or any other medium like Common Payment Page or SPlless if request is rejected by IPG or fails to complete at any stage IPG returns its specific errors To troubleshoot any errors by IPG please refer to FAQ Document IPG Features Document Merchant Integration Support 66 cla etisalat 9 MERCHANT PORTAL IPG Merchant Portal sometimes also referred as Web Ul is specially designed to help the customers to view their IPG account online in a Microsoft Silverlight application The application provides a querying interface to customers to see Registered Authorized captured reversed and declined orders They can request payment for fulfilled orders perform adjustments such as reversals and generate reports for transactions IPG Merchant Portal can be accessed online at following links Production https ipg comtrust ae merchant Staging https demo ipg comtrust ae merchant Manual for Merchant Portal can be downloaded from Downloads section in Merchant Portal NOTE Merchant Portal is recommended to be accessed using Internet Explorer or Google Chrome browsers Mozilla Fire Fox is not supported to access transaction details IPG Features Document Merchant Integration Support 67 Vail etisalat 9 MERCHANT INTEGRATION TEST
9. Recurring Payment through Authorization Call or Registration Call In step two there are following two options to do the recurring payment 3 4 2 1 Option 1 Recurring Payment through Registration Call for a registered Credit Card To make payments against an already registered Credit Card for recurring payments SPI Registration call is sent using implementation of Registration Model Section 3 2 with following changes e Inthe registration call RecurrencelD returned by SPI Finalization call in STEP Section 3 4 1 will be provided in the ExtraData property of registration call with the name RecurrencelD and the value of the RecurrencelD Refer to section 5 3 7 for more information on ExtraData Following is an example how the RecurrencelD can be set in the registration call IPG Features Document Merchant Integration Support 31 bail etisalat pay SetProperty ExtraData RecurrencelD Put here TransactionID of Original Registration Transaction Following things must be noted or considered once SPI Registration call is identified as a recurring payment call e Each call will automatically get and use the Credit Card details saved during registration in step 3 4 1 e Once Payer is redirected to the payment portal Payer will not be required to provide the credit card details other static information will be displayed on the payment portal like amount currency etc e f the Credit Card is 3d secure payer will
10. a Merchant internal workflow erchant internal workflaw Process complete i Process Registration Request Redirected to redirection link provided by merchant in SPI Registration call Pull data against Transaction ID and process transaction with bank to block the amount ustomer ID Transaction ID H Payment response Capture Reverse Transaction for full Transaction ID amount if amount is Customer ID not mentioned else apture Reversal process only the mentioned amount after validating available blacked amount Amount only if partial Capture Reversal is required Currency only if partial Capture Reversal is required Figure 8 IPG Features Document M erchant Integration Support 28 ula etisalat This model includes three calls minimum to IPG using SPI For SPI documentation please refer to Section 5 SPI USER GUIDE Please read the manual for SPI Registration Finalization Capture see partial capture as well Reversal see partial reversal as well calls In SPI downloads package a sample can be found for Auto Capture transactions SPI Calls c Registration d Finalization e Capture Reversal required only in case Manual Capture has been configured Please refer to section 5 2 SPI Calls for any help and documentation related to above mentioned SPI calls Note Please strictly follow the calling sequence 3 3 3D Secure Model In compliance
11. 65 7 FAQs AND KNOWLEDGEBASE secgzcciscececasccnesceusdecs sanccnnd Dario e iegbee voices ai ae 66 8 MERCHANT PORTAL vwcssscccsissaccansazsaccgateundsouctexesgatscinaegacssnaadesonsbanhauencesh aaiae E Eege ASSEN testes 67 9 MERCHANT INTEGRATION TEST CASES cono c cnn nc nn nc nn nn nn narran naar carr annc anna 68 Use Case 1 Merchant Configuration Registration confirmation on IPG Staging Server 69 Use Case 2 Common Payment Page CPP appears with correct settings and values 70 Use Case 3 Merchant Configuration Finalization on IPG Staging Server 70 Use Case 4 Capture Reversal on IPG Staging Server ooooncccnnccnnconnnononnnonanononnnonnnonnnnnonnnnrnnnnnonnanannacorinnnos 71 Use Case 5 Verify closing of a transaction on IPG Staging Server ooooccconccnnocononnnononnnonononnnnncnnnnnnnnnnnnans 72 IPG Features Document Merchant Integration Support bail etisalat IMPORTANT CONTACTS Comtrust Support 24 7 support comtrust ae 800 2900 Comtrust Support is the first level support for Etisalat Payment Gateway related issues This team is available 24 7 for any issues related to IPG production environment and should be contacted in the first place in case any live customer gets a payment related issue Once contacted this team is responsible to rectify the issue and forward it to related team for resolution This support group has to be contacted for merchant provisioning updating merchant settings or any issues rel
12. A Merchant logo can be used on this payment portal to identify the merchant The Merchant can modify design fonts color schema layout of the Payment Portal to make it appear to be a part of the merchant s website Credit Card A payment card that enables the holder to make purchases and to draw cash up to a pre arranged limit Credit Card Processing Once the payment gateway accepts the transaction this service records the transaction removes funds from the credit cardholder s account and deposits these into the merchant account CVC2 amp CVV2 Card Validation Code 2 amp Card Verification Value 2 VISA and MasterCard implemented a security code feature known as CVV2 and CVC2 The security code is a 3 digit code imprinted on the physical credit card but not embedded or encrypted in the magnetic stripe The code is a 3 digit number located on the signature strip on the back of Visa and MasterCard cards after the card number This three digit code helps validate that the cardholder has the card in his her possession and the account is legitimate IPG Features Document Merchant Integration Support ula etisalat Debit Card A payment card linked to a bank account used to pay for goods and services by debiting the holder s account usually also combined with other facilities such as ATM and cheque guarantee functions Digital Certificate A digital certificate is an electronic
13. CASES Merchant Integration Support team is keen to provide best support for new IPG merchants in new integrations to IPG Support team helps the new merchants at every step to make the integration smooth and error free Once a merchant is done with successful integration and POC Proof of Concept of online payments through IPG using test merchant account Demo Merchant Merchant Integration Support team sets up merchant account on IPG Staging server with exact settings as required by the merchant to be used on IPG Production server before merchant goes live Added benefit for this setup is to make sure that there are no issues in IPG integration process and once merchant decides to go live he just has to point to IPG Production server for live transactions This section of the document covers the test cases to be executed before going live to be sure that integration has been done properly hence minimizing any chances of issues and unwanted delays while going live IPG Features Document Merchant Integration Support 68 ula etisalat Use Case 1 Merchant Configuration Registration confirmation on IPG Staging Server Use Case Merchant Configuration Registration confirmation on IPG Staging Server Description Confirmation that the SPI has been configured properly and is able to send correct Registration call Sources e https demo ipg comtrust ae merchant downloads IPGManual pdf e https demo ipg
14. Card IPG Features Document Merchant Integration Support 30 ula etisalat Implementation Implementation of Recurring Payments is a two step process 3 4 1 Step 1 Registering Credit Card for recurring payments To register a Credit Card for recurring payments a normal SPI Registration call is sent using any implementation of Redirection Model Section 3 1 Following parameters needs to be added to identify that call is treated for registering a Credit Card Parameter Value Recurrence Type M Following things must be noted or considered once SPI Registration call is identified as a recurring payment call e None of the SPI calls taking part in Redirection Model Section 3 1 life cycle will be changed in any way except for the above mentioned change SPI Registration call e TransactionID returned in SPI Finalization call will be treated as RecurrencelD to be used in future recurring payment calls this is the reference merchant needs to store to point to card details just saved for recurring payments e Returned TransactionID will also be treated as unique reference for current payment e This call will redirect the payer to IPG Common Payment Page where payer will be prompted to provide Credit Card information On successful authentications including verification code and 3D Secure if configured the amount mentioned will be processed and Credit Card data will be saved for future reference 3 4 2 Step 2
15. CardNumber and SecureCode or only CardTrack2 Please make sure to send either ExpiryYear and ExpiryMonth For Recurring Payment call do not provide CardNumber SecureCode ExpiryYear SecureCode or CardTrack2 5 2 4 Capture For any transaction in IPG whether it is following Redirection Model refer to section 3 2 or Authorization Model refer to section 3 1 a transaction can be marked to be captured automatically or manually For manual capture if amount has to be transferred from payer to merchant SPI Capture call is required Capture has two modes e Complete Capture Total outstanding balance amount is captured e Partial Capture Portion of outstanding balance amount is captured Following are the properties used in SPI Capture call for both modes Property Usage Comments Request Properties Customer Customer ID Please refer to section 5 3 3 for MANDATORY Customer details Store Store Please refer to section 5 3 3 for Store details OPTIONAL Terminal Terminal Please refer to section 5 3 3 for Terminal OPTIONAL details Channel Payment Channel Please refer to section 5 3 3 for MANDATORY Channel details Transaction ID TransactionID returned in SPI Registration or MANDATORY Authorization call Amount Amount to be captured This Amount should be less MANDATORY for than or equal to outstanding balance amount Partial Capture Currency Currency in which above mentioned amount is to be MA
16. Recurring Payments Recurring Payments is a solution where a Merchant wants to save Credit Card information sensitive data and payer gives him permission to make future transactions on his behalf or may be on just one click by payer payer does not need to provide same Credit Card information again and again for his future transactions As per PCI standards only PCI compliant companies are allowed to store any Credit Card sensitive data like card number Every merchant who wants to implement Recurring Payments kind of functionality cannot afford to be PCI compliance So IPG is providing Recurring Payments feature where merchants will redirect the payers to IPG where they ll provide their Credit Card details IPG will authenticate provided data and return a reference for saved Card details for future Recurring Payment call from same Merchant for that specific Credit Card 2 6 BizDirect Direct Debit Payments BizDirect is a payment mechanism that would offer individuals and corporate users the ability to pay for ecommerce services directly from their bank account This payment can be performed from within the secure internet banking environment available from their bank 2 7 Any Device Capable to Integrate SPI Generally any device that can integrate SPI for example devices running Java VM or operating on Microsoft Windows may easily integrate SPI and hence can make payments IPG Features Document Merchant Integration Support 16
17. Redirection Model Payment Data is not shared with merchant but only with payment gateway acquirer and payment scheme lene e ele ee Shopping Cart Payment Scheme Key Data exchange E with no payment sensitive information with sensitive payment information Payer Buyer Figure 6 Redirection Model in IPG can be adapted in two ways implementation of suitable method is important in Merchant s business context only explained below 3 2 1 Auto Capture Card Not Present Scenario Introduction Auto Capture allows the Merchant to process the transaction without any delays between blocking of the amount from payer s Payment Instrument and capturing it to finally process the transaction with bank In this scenario Merchant is telling IPG that he has already verified the transaction and IPG should process it immediately It automatically closes a transaction after successful payment Auto Capture is recommended if your business flow does not need any physical logical authentication validation for example a retail store IPG Features Document Merchant Integration Support 25 un lail etisalat Implementation Merchants can integrate to IPG for Auto Captured transaction using SPI can be downloaded from https demo ipg comtrust ae merchant downloads Figure 7 explains the technical work flow of an Auto Capture transaction Redirection Model Auto Capture Buyer Merchant EP
18. Redirection Model Redirection Model is a more secure way considered for online payments where Merchant seller redirects his Customer buyer to Payment Gateway provided page exposed on Payment Gateway network buyer provides his credit card related information to Payment Gateway directly and is redirected to seller website after authentication and other checks by Payment Gateway This model is secure as Payment Instrument for example Credit Card related data is not handed over to any untrusted party according to PCI standards any non PCI compliant party cannot save credit card information Following steps take palace in context of a buyer when Redirection Model has been implemented 1 Buyer verifies on Merchant s web site that he wants to pay for the purchases Merchant s web site redirects the buyer to secure and trusted Payment Page provided by IPG 3 Buyer provides Payment Instrument related information to IPG Common Payment Page CPP IPG Features Document Merchant Integration Support 24 Vail etisalat 4 On authentication and verification CPP redirects the buyer back to Merchant s web site and Merchant displays the status of transaction to the customer Hence enforcing that no Payment Instrument related information has been provided to and or kept by the Merchant non PCI compliant party Figure 6 shows the business workflow of a transaction following Redirection Model Limited Disclosure Transaction Model
19. SPInet For windows based server environments our recommended flavor of SPI is SPlnet SPlnet has been built in Microsoft NET Framework SPlnet versions for both NET Framework 2 and NET Framework 3 or higher can be downloaded from the download link provided in section 5 We highly recommend using SPInet for NET Framework 3 or higher 5 1 2 1 System Requirements e Any machine capable of running Microsoft NET Framework e Microsoft NET Framework e TCP connectivity to Internet Payment Gateway refer to section 5 1 1 5 1 2 2 Installation 1 Copy SPI dll provided in SPInet download package into your system 2 Add reference to copied SPI dll into your project 5 1 2 1 SSL Requirements In order to be able to establish a secure connection to IPG merchant has to poses a client certificate refer to section 5 1 1 3 To install the certificate see the instructions mentioned in section 5 1 1 3 5 1 2 2 Configuration Run SPIConfig exe provided under Configuration Utility folder in specific SPInet download package For initial testing and configuration use the following configurations Property Value Bold value is for sample for testing Customer Demo Merchant This is the customer id as provided by IPG in Work Order IPG Features Document Merchant Integration Support 44 ula etisalat Channel leave it blank Payment channel through which payments has to
20. and is ready for data entry Merchant will verify that he sees all the payment options as of Work Order for example Card Brands etc e Enter valid data and click Pay button to ensure nothing goes wrong or unexpected e Open https demo ipg comtrust ae merchant using Merchant certificate search for the TransactionID returned as a result of successful Registration call open details of transaction and verify that successful PaymentPage Query call is in place Issues e Failure to load CPP IPG introduction page appears This normally happens in case a valid TransactionID has not been provided at the time of redirection to CPP e All or some card brands not shown as of Work Order e Detect any unwanted wrongly implemented policies scenarios e Transaction Data not valid as of Registration call e Unable to proceed to next step Finalization that is initiated after clicking Pay button Comments Incase anything is confusing still getting any issues while making payment please contact merchant integration etisalat ae Merchant Integration Support Use Case 3 Merchant Configuration Finalization on IPG Staging Server Use Case Merchant Configuration Finalization on IPG Staging Server IPG Features Document Merchant Integration Support 70 ula etisalat Description Confirmation that the SPI has been configured perfectly and is able to send correct Finalization call Sourc
21. be made if not provided default is Web Store leave it blank May or may not be provisioned to your account as per Work Order Terminal leave it blank May or may not be provisioned to your account as per Work Order Address demo ipg comtrust ae IPG Server address Port 2443 Communication Port Timeout 120 Timeout for request in seconds Secure SSL True Certificate Path of Demo Merchant certificate file having private key pfx file refer to section 5 1 1 3 Certificate file path for the certificate provided by PKI Password Comtrust Password for the client certificate file pfx file provided at the time of exporting certificate with private key refer to section 5 1 1 3 Card Number 999000000000029 999000000000003 999000000000011 Test Cards Currency AED Expiry Month Any Credit Card expiry month Expiry Year Any Credit Card expiry year Providing these configuration properties and clicking the Test button will fire a transaction and if Response Code returned is O it means configurations are fine for Demo Merchant customer To test the configuration for your user provide the properties w r t your user from Work Order and hit Test button to fire a transaction from your account To resolve the issues if faced see the document mentioned in section 1 1 to get the Response Code 0 SPInet configurations can be done in two ways 5 1 2 2 1 Loading from configurations file Once Configuratio
22. comtrust ae merchant downloads IPGKnowledgeBase pdf e https demo ipg comtrust ae merchant Using Digital Certificate with Merchant Portal permissions provisioned e Any user manual for specific SPI version provided with in the SPI download package Assumptions Developer has downloaded specific SPI version has gone through the user manuals and has successfully done the integration with Demo Merchant account Merchant has received Business User Certificate from Etisalat PKI Merchant has got the Business User Certificate provisioned for transactions Actors e Merchant e Merchant Integration Support Steps e Merchant will send SPI Registration call to IPG Staging server e Merchant Integration Support will verify the received values of the properties sent e Open https demo ipg comtrust ae merchant using Merchant certificate search for the TransactionID returned as a result of successful Registration call open details of transaction and verify that successful Registration call is in place Issues e Verify validate the values properties sent to SPI at the location where the value is being set into SPI Verify that ReturnPath is internet accessible link localhost or local server link cannot be accessed resolved by client machine when client will be on internet and not on Merchant s local network e Verify all sent properties to be same as mentioned in the following list Property sent to S
23. for which brands Payment Portal should require payer to enter Verification Code i e CVV2 CVC2 CID VCC tag will control verification codes for all brands while CVV CVC CID will control it for specific brand only e g VCC Y ask verification code for all brands Default behavior VCC N don t ask verification code for any brand CVV Y ask verification code for Visa CVV N don t ask verification code for Visa CVC Y ask verification code for MasterCard CVC N don t ask verification code for MasterCard CID Y ask verification code for Discover AMEX CID N don t ask verification code for Discover AMEX Card Tokenization whether to apply or not can be defined in the configuration CTK Use CustomerID as seed CTK X X will represent a custom seed Char for card tokenization CTK E Tokenization seed for Etisalat IPG Features Document Merchant Integration Support 58 ula etisalat Multiple hints within TransactionHint have to be separated by semicolon e g pay SetProperty TransactionHint CPT N VCC Y SCN A Hints specified by merchant as part of transaction take precedence over those set in merchant profile on payment gateway OrderlD This can serve two different purposes you can either specify an order ID here or ask system to generate one It can consist of text and special sequences the total length once the sequences are expanded cannot excee
24. legacy applications using COM Components 5 1 4 1 System Requirements e Any machine and operating system capable of Microsoft Net framework 4 or later e TCP connectivity to Internet Payment Gateway refer to section 5 1 1 5 1 4 2 Installation e Download SPIs package from the Download link provided in section 5 e Run setup msi file available in the package e Choose default location for installation e After installation is completed go to installation directory Program Files Comtrust Integrated Payment Gateway SPI Service if default installation is chosen e Run SPIConfig exe 5 1 4 3 SSL Requirements In order to be able to establish a secure connection to IPG merchant has to poses a client certificate refer to section 5 1 1 3 which is trusted by IPG and allows SPIj to trust the certification authority which issued IPG server certificate The certificates are kept in two different stores SPIMerchant store and SPIMTrust store The first one is client certificate while the second one contains the list of trusted authorities Client certificate can be acquired by following the steps mentioned in section 5 1 1 3 5 1 4 4 Configuration Refer to SPls Integration Guide provided in SPls package 5 1 5 SPILess SPlLess is usually used whenever using SPI is not an option however you ll be very limited in what you can do with it and it ll required more manual effort from your side The payment gateway uses the combinatio
25. opt not to capture IPG Features Document Merchant Integration Support 37 ula etisalat transaction and eventually reverse it Merchants should not rely on the online status of the transaction for any other reason than to notify the operator about the need of a manual review and a general thank you message SPlLess Payments cannot support merchants selling services which do require immediate delivery and is not recommended for high volume merchants due to the need of manual verification for each transaction SPlLess is the ideal solution for charities which may use any free hosting offering and are not exposed to fraud 4 1 2 MOTO The merchant has multiple possibilities for processing MOTO transactions Authorization Model explained above in detail applies to these kinds of transactions 4 1 2 1 Standard authorization call In the MOTO mode the merchant receives payment details directly from the payer over the channel where the Payment Portal does not exist In these cases the merchant can enter payment details into their internal application or even website and initiate the transaction using the Authorization method The merchant cannot use the same application as for web based payments just operated by their staff as using the web payment method indicates that the payment details have been entered by payer himself The Merchant processing transactions using this method is subject to PCI DSS review both for merchant pr
26. physically present at the time of transaction In addition the payer has to physically hold payment token this is usually in form of a card although contactless payment tokens can be used In most cases POS transaction requires either a signature or an electronic pin hence POS terminals are manned While payment happens through electronic means POS are seldom used in eCommerce applications as manned terminals remove most of benefits of electronic fulfillment POS terminals are usually connected directly to the acquirer bank but in big organizations they could be linked through a payment gateway which in turn provides centralised rules reconciliation and reporting 2 2 Web Based Payments The most popular electronic transaction type in the eCommerce landscape is web based payment It provides the widest reach with the most user friendly and attractive user interfaces combined with the ability for the payer to securely hand over important information directly to the trusted party Conversely majority of web based transactions depend solely on information printed on the payment token as only information known to payer could be used This provides an opportunity for unauthorised usage of the payment token information for fraudulent activities in the situation when this information is acquired by someone purporting to be the payer Furthermore the anonymous nature of the media Internet makes it very difficult to have independent information on
27. the origin of the transaction While IP addresses may play a role there are multiple situations where they do not bring additional value Over time several approaches were developed to make web based transactions more secure with two main streams The first one involved the securing of web based transactions without direct input help from issuer of the payment token those systems called fraud detection or fraud monitoring systems had the capability to either verify extra data not printed on the card i e card issuer name country of issuance or crosscheck the provided information with other data known i e IP address shipping address These systems can analyze transaction behavior e g number of transactions with the same card and eliminate issuers countries systems i e open proxies where most fraud is known to be originated or where legislation supporting merchants in seeking legal recourse against fraudsters is absent The most advanced systems offered score based systems where each transaction could be scored against multiple criteria or even elements of artificial intelligence IPG Features Document Merchant Integration Support 14 ula etisalat The other steam is based on information directly verified by issuer of payment token this could be card holder name billing address or any other information known to issuer Unfortunately in the long run the information collected by merchant proved to affect the payer s pr
28. 5 1 1 3 Digital Certificate For secure communication with IPG SPI needs to establish an SSL connection to IPG server using Digital Certificate issued by Etisalat Merchant can apply for a Digital Certificate Business User Certificate at https comtrust etisalat ae enrollment a eneral DirBusinessUser It is highly recommended that when you get your certificate from PKI you perform the following procedure Make sure that certificate is in proper format it should be password protected by importing your certificate into any windows system and export it to get two copies using default properties e With private key never to be shared with anyone even IPG team e With private key and without certificate chain for SPIj e Without private key IPG Features Document Merchant Integration Support 43 ula etisalat Quick way to import install the certificate in windows based machine is double click the pfx file and follow the instructions through the wizard carefully keeping above mentioned 2 points in mind For instructions on importing or exporting Digital Certificates please refer to http technet microsoft com en us library cc782788 WS 10 aspx Note Certificate cannot be sent again If lost you have to apply for a new certificate For testing test certificate for test merchant Demo Merchant can be downloaded from downloads link provided above in section 5 Password for all Demo Merchant certificates is Comtrust 5 1 2
29. English AR Arabic IPG Features Document Merchant Integration Support 57 ula etisalat QQ Technical descriptions detailed description suited for troubleshooting and testing but not recommended to be used as an end user messages Amount It represents the transaction amount in standard format with dot as a separator e g 12 34 Currency Transaction s currency as ISO currency code e g 840 for US Dollar 874 for UAE Dirham or ISO currency name e g USD for US Dollar AED for UAE Dirham Please refer to following link for complete list http www currency iso org iso_index iso tables iso tables al bm TransactionHint This property is used to specify which payment instruments should be available to the buyer Merchant can specify which features should be supported by payment instrument i e later reversal capture partial reversal partial capture etc Additionally a merchant can request the final step to perform either authorization and capture or authorization alone e g CPT N only authorization Manual Capture CPT Y authorization and capture Auto Capture Default behavior Merchant can also use this property to select one of scenarios which has been configured on Payment Gateway SCN lt scenario letter gt e g SCN X X is the Scenario ID as configured and communicated by IPG team for a particular type of transaction scenario For controlling whenever and
30. G Provide credit card info and other validation authorization checks SPORT RS Card holder wants SPI Registration to pay on merchant Merchant internal workflow _ TransactionHint Registration XML website CPT Y cd ERRA Process Registration PP with available payment options Common Payment Transaction 1D Common Payment Page link See Page Payment complete lerchant internal workflo Process Response Payment respon Credit card data SPI Finalization Redirected to redirection link provided by merchant in SPI Registration call Pull data against Transaction ID and process transaction with bank to block the amount ustomer 1D Transaction Capture Transaction for full amount Figure 7 This model includes two calls to IPG using SPI For SP documentation please refer to Section 5 SPI USER GUIDE Please read the manual for SPI Registration and Finalization calls In SPI downloads package a sample can be found for Auto Capture transactions SPI Calls a Registration b Finalization IPG Features Document Merchant Integration Support 26 ula etisalat Please refer to section 5 2 SPI Calls for any help and documentation related to above mentioned SPI calls Note Please strictly follow the calling sequence 3 2 2 Manual Capture Card Not Present Scenario Introduction Manual Capture allows the Mer
31. NDATORY for charged This Currency should be same as that of Partial Capture mentioned in SPI Registration or Authorization call IPG Features Document Merchant Integration Support 54 ula etisalat TransactionHint Only allowed value is RVS Y or RVS N which indicates whether remaining part of balance should be reversed automatically or not OPTIONAL Response Properties TransactionID Reference for ongoing transaction Balance Outstanding balance after current transaction 5 2 5 Reversal For any transaction in IPG whether it is following Redirection Model refer to section 3 2 or Authorization Model refer to section 3 1 a transaction can be marked to be captured automatically or manually For manual capture if amount has to be unblocked for not to be transferred from payer to merchant SPI Reversal call is required Reversal has two modes e Complete Reversal Total outstanding balance amount is reversed unblocked e Partial Reversal Portion of outstanding balance amount is reversed unblocked Following are the properties used in SPI Capture call for both modes Property Usage Comments Request Properties Customer Customer ID Please refer to section 5 3 3 for MANDATORY Customer details Store Store Please refer to section 5 3 3 for Store details OPTIONAL Terminal Terminal Please refer to section 5 3 3 for Terminal O
32. PI Verification Source Customer Customer ID Work Order Currency Merchant Currency Work Order Please verify currency code supplied from SPI user guide Channel Not needed in case only 1 default channel has been provisioned Store Not needed in case only 1 default store has been provisioned Terminal Not needed in case only 1 default terminal has been provisioned IPG Features Document Merchant Integration Support 69 ula etisalat Certificate Path Is this pointing to same as received from Etisalat PKI Language Check language codes from SPI user guide IPG Connection Address demo ipg comtrust ae Comments Incase anything is confusing or still getting any issues while making Registration call please contact merchant integration etisalat ae Merchant Integration Support Use Case 2 Common Payment Page CPP appears with correct settings and values Use Case Common Payment Page CPP appears with correct settings and values Description Common Payment Page appearing as a result of Registration contains loads the requested and provisioned payment instrument card brands and other related settings Sources e https demo ipg comtrust ae merchant Using Digital Certificate with Merchant Portal permissions provisioned Assumptions e Merchant has been able to make a successful Registration call and has verified Use Case 1 Actors e Merchant Steps e Once CPP loads
33. PTIONAL details Channel Payment Channel Please refer to section 5 3 3 for MANDATORY Channel details Transaction ID TransactionID returned in SPI Registration or MANDATORY Authorization call Amount Amount to be reversed unblocked This Amount MANDATORY for should be less than or equal to outstanding balance Partial Reversal amount Currency Currency in which above mentioned amount is to be MANDATORY for charged This Currency should be same as that of Partial Reversal mentioned in SPI Registration or Authorization call IPG Features Document Merchant Integration Support 55 ula etisalat Response Properties Transaction ID Reference for ongoing transaction Balance Outstanding balance after current transaction NOTE If outstanding balance is greater than zero multiple Capture and or Reversal calls can be posted to IPG in order to finally get outstanding balance as zero 5 3 SPI Transaction Properties In reference to SPI Calls please refer to section 5 2 this section deals with the details valid values and any other significant information related to the properties required or returned by SPI 5 3 1 Connection Properties Property Description ConnectionAddress DNS name of Payment Gateway Note Due to the way SSL connections work it is not possible to establish a secure connection to the IP address in a form of xx xx xx xx e g 195 229 85 91 in order to e
34. action for full Transaction ID amount if amount is SPI Capture Customer ID not mentioned else Or Capture Reversal gt process only the SPI Reversal Amount only if partial Capture Reversal is required mentioned amount Currency only if partial Capture Reversal is required after validating available blocked amount Process Response Payment response Merchant internal workflow 5 E Pr E Payment complete Merchant internal workflow _ Process complete E vi 5 SS p z 2 a Figure 5 IPG Features Document Merchant Integration Support 23 ula etisalat For SPI documentation please refer to Section 5 SPI USER GUIDE Please read the manual for SPI Authorization Capture and Reversal calls For Card Present transaction we need to implement Authorization call with a little change which is as follows e Ignore all Credit Card related fields CardNumber ExpiryYear ExpiryMonth and SecureCode e Provide Credit Card Track 2 Data in property Track2Data Authorization call takes all Merchant and Credit Card related data processes the payment with the payment parties and returns the response Complete processing is done in single call SPI Calls a Authorization b Capture Reversal required only in case Manual Capture has been configured Please refer to section 5 2 SPI Calls for any help and documentation related to above mentioned SPI calls Note Please strictly follow the calling sequence 3 2
35. ated to IPG Production server PKI Support pkihelp eim ae pkira etisalat ae PKI Support group deals with the issues related to Digital Certificate issuance installation Operations Ops team eim ae Operations Team is the second level support for IPG and is responsible for maintaining and monitoring IPG Production server Merchant Integration Support 7 AM 3 PM Merchant integration etisalat ae Merchant Integration Support group is responsible for the configuration and integration of IPG merchants into the IPG This group also deals with any issues raised for IPG Staging server This group is the third level of support for IPG and handles the cases for Production server only when contacted by first or second level support Availability is strictly between office hours 7 AM 3 PM UTC 04 00 IPG Features Document Merchant Integration Support Vail etisalat 1 INTRODUCTION Integrated Payment Gateway IPG offers customers a comprehensive payment collection solution It is a proprietary payment platform that enables real time authorization of payment transactions from Visa MasterCard Diners Club JCB and American Express This easy and quick start package provides a reliable affordable and secure payment mechanism for ecommerce retailers In addition the platform is able to accept and process debit cards BizDirect Direct Debit eDirham transactions as well as other customized payment instruments IPG Featur
36. be requested to provide the 3d secure information Once authorized successfully payer will continue with the payment and will be redirected to the provided merchant URL from where the merchant can initiate the finalization call e This subscription for recurring payments will stay valid till Credit Card expiry date e Any details for a registered Credit Card cannot be changed e Payer will be asked to enter CVV for subsequent recurring 3D transactions e A new and unique TransactionID will be returned as a reference against each SPI Registration call please don t confuse and or replace Subsequent Recurring Transaction with the Original Registration Transaction Note This is a 3d secure model and payer card will be authenticated each time the recurring payment is being made Disclaimer Please note that for Recurring 3D transactions business rules that involve fees or discounts can t be used Such business rule hint will fail the transaction flow 3 4 2 2 Option 2 Recurring Payment through Authorization Call for a registered Credit Card To make payments against an already registered Credit Card for recurring payments SPI Authorization call is sent using any implementation of Authorization Model Section 3 1 with following changes e Credit Card number should be skipped and not mentioned e Credit Card expiry fields should be skipped and not mentioned e Verification Code should be skipped and not mentioned IPG Features Doc
37. certificate that establishes credentials when performing transactions on the Web The certificate is issued by a Certification Authority in this case IPG Electronic Funds Transfer EFT EFT is a technology one of the electronic commerce technologies that allows the transfer of funds from the bank account of one person or organization to that of another EFT is also used to refer to the action of using this technology It is an important addition in the organization that implements EDI in their organization Encryption A method of ensuring data secrecy The message is coded using a key available only to the sender and the receiver The coded message is sent to the receiver and then decoded upon receipt Firewall A computer system that sits between the Internet and a company s LAN Itis a means of automatically limiting what a company s computer system will pass along to outside computer systems It acts as an active gateway to keep non company entities from accessing company confidential data Gateway Most generally a computer that forwards and routes data between two or more networks of any size MasterCard SecureCode MasterCard SecureCode is a new service to enhance the user s existing MasterCard account A PIN code will be linked to the credit card for added protection against unauthorised use of the card when dealing with online merchants Similar technology by VISA is known as VERIFIED by VISA Merc
38. chant to only block the amount mentioned in Registration To process and close the transaction Merchant needs to initiate Capture or Reversal call separately after successful Finalization call This process gives Merchant chance to validate the order before processing the payment Manual Capture is used if business requires any physical logical authentication validation like in case you have to validate a physical delivery address or amount has to be captured subject to goods received Implementation Merchants can integrate to IPG for Manual Captured transaction using SPI can be downloaded from https demo ipg comtrust ae merchant downloads Figure 8 explains the technical work flow of a Manual Capture transaction IPG Features Document Merchant Integration Support 27 un lail etisalat Redirection Model Manual Capture Buyer Merchant EPG Card holder wants to pay on merchant website Provide credit card info and other validation authorization checks Authorization complete waiting for approval Phase Transaction Payment complete Phase Finalization PP with available payment options SPI Registration lerchant internal workflow _ TransactionHint CPT N Redirect to Etisalat Common Payment Page Process Response lerchant internal workflo Merchant internal workflow SPI Capture or SPI Reversal
39. complete waiting Ly 5 for capture call to be Merchant internal workflow Process Response Payment response S Asent by merchant g E 8 Merchant SEH Capture Reverse a A eeh transaction having amount already J blocked Merchant internal workflow Capture Reverse Transaction for full Transaction ID amount if amount is SPI Capture Customer ID not mentioned else Or Capture Reversal gt process only the SPI Reversal Amount only if partial Capture Reversal is required mentioned amount Currency only if partial Capture Reversal is required after validating available blocked amount Process Response Payment response Merchant internal workflow g ZS ee ec y an ZS Payment a Merien internal workflow Process cos E SS q a S E Figure 3 IPG Features Document Merchant Integration Support 20 ula etisalat For SPI documentation please refer to Section 5 SP USER GUIDE for calls included in Card Not Present transactions Please read the manual for SPI Authorization Capture and Reversal calls Authorization call takes all Merchant and Credit Card related data processes the payment with the payment parties and returns the response Complete processing is done in single call SPI Calls a Authorization b Capture Reversal required only in case Manual Capture has been configured Please refer to
40. d 16 characters Special sequences o Date Time sequences _ Y year yyyy format _ y year yy format _ im month mm format _ b month 3 letters long abbreviation e g Jun Feb etc _ d day dd format _ a day of the week 3 letters long abbreviation e g Sun Mon _ H hour 24 hour system _ 1 hour 12 hour system _ p AM PM indicator _ m minutes _ S seconds _ L number of milliseconds _ j Julian day the day number starting from 1st of January _ U week of the year assuming Sunday is the first day _ W week of the year assuming Monday is the first day _ w day of week Sunday 0 Monday 1 etc OrderName Short description of the order The OrderName has to be shorter than 25 characters It can contain only printable Unicode characters and it cannot neither start nor end nor have to adjacent white characters OrderlInfo Long description of the goods which are being purchased this will be displayed on Common Payment Page as a tooltip The OrderInfo has to be shorter than 256 characters It can contain only printable and end of line Unicode characters and it cannot neither start nor end nor have to adjacent white characters IPG Features Document Merchant Integration Support 59 ula etisalat TransactionID Transaction reference number This is returned by IPG itself in response of SPI Registration call
41. d for Auto Capture instead of Manual Capture hence not available for the process and is Closed e Amount greater than available amount to be captured has been entered e Currency provided is a mismatch to the one provided in Registration call Comments Incase anything is confusing still getting any issues while making Registration call please contact merchant integration etisalat ae Merchant Integration Support Use Case 5 Verify closing of a transaction on IPG Staging Server Use Case Verify closing of a transaction on IPG Staging Server Description Confirmation that the transaction has been closed and amount has been captured reversed Sources e https demo ipg comtrust ae merchant downloads IPGKnowledgeBase pdf e https demo ipg comtrust ae merchant Using Digital Certificate with Merchant Portal permissions provisioned Assumptions e All use cases run resulted success Actors e Merchant Steps e Open https demo ipg comtrust ae merchant using Merchant certificate search for the TransactionID open details e In case of Auto Capture make sure there exists only 1 CC Capture call after CC Authorization call with full amount captured at once e In case of Manual Capture Multiple CC Capture and CC Reversal calls can be in place in accordance to the number of Capture Reversal calls sent to IPG e Make sure that transaction status second text field in first row of fields at top of page is closed
42. e look and feel in several ways The simplest one by default contains the merchants beneficiary details including merchant name city and country The Merchant can also add their own logo place the Payment Portal within the frame of their website and even create their own style sheet 4 1 1 2 Merchant payment entry page using authorization API In certain cases the merchant may want to have full control over the input of card information by payer they may have certain rules which cannot be easily translated into the form of scenarios or wish to make payment information entry an integral part of their website In these cases the merchant can collect payment details on their side through the page developed by their team The merchant payment information entry page has great value for the merchants that want to maintain a consistent look and feel through the whole process which is not always possible even when using style sheets Further benefits include allowing the merchant to take multiple decisions and even include the whole workflow from the moment the payment data was provided to processing the transaction through IPG However acceptance of payment data has its own cost as the merchant is subject to PCI DSS rules regarding storage of sensitive data IPG Features Document Merchant Integration Support 36 ula etisalat and processes around it The merchant application should preferably possess knowledge of card ranges belongin
43. ePas Password of the keystore which contains certificates of SPIj sword certification authorities As file SPIMTrust is to be copied from SP downloads package password for that file is password 5 3 3 Point of Sale Properties Property Description Customer This property maps to Customer ID as mentioned in Work Order for testing on staging Demo Merchant should be used as Customer ID Channel Payment Channel to be used for the transaction Acceptable Values e Web default e Terminal e POS e Recurring e Phone e Mail e USSD Store The name of the store this property is optional unless the merchant requested support for more than one store or the default store has not been provisioned in Payment Gateway Merchant Integration Support team advises the merchant on its usage upon request Terminal The name of the terminal this property is optional unless the merchant requested support for more than one terminal or the default terminal has not been provisioned in Payment Gateway Merchant Integration Support team advises the merchant on its usage upon request 5 3 4 Transaction Properties Property Description Language This property can be used with any request and it specifies which language is used for error message descriptions In order to display messages correctly the proper language code page has to be installed on the server Currently defined languages EN
44. em that ensures that the cardholder is who they say they are Work Order Work Order in other words is the service order containing all the information related the merchant configuration acquirer bank and other configuration and contractual information IPG Features Document Merchant Integration Support 12 cla etisalat 2 TRANSACTION TYPES The Internet has become a vital part of people s lives providing more and more consumers with the option to shop pay bills bank and invest online through the use of electronic payments ePayments Electronic Commerce or eCommerce in short consists of any transaction where the buying and selling of products and services is conducted over electronic channels In most cases these transactions involve electronic payment which could take any form of Electronic Fund Transfer EFT including credit card payment direct debit and even standing instructions This section describes types of electronic payment transactions that are critical in deciding the ePayment Solution best suited for a Merchant 1 Point of Sale PoS Web Based Payments Mail Order Telephone Order MOTO Card Activated Terminal BizDirect Direct Debit Payments Any Device Capable to Integrate SPI St MA AA IPG Features Document Merchant Integration Support 13 ula etisalat 2 1 Point of Sale POS Most common form of electronic payment transaction is POS mode In this mode the payer has to be
45. ent request In these cases a message should be displayed stating the actual status of the payment transaction The payer should be informed of the necessary steps to be taken to receive their service or when the service can be delivered In case the merchant cannot store the transaction status in their system due to a technical problem the payment gateway TransactionID ApprovalCode and information regarding how the payer should contact a merchant to complete transaction should be provided In these circumstances the merchant contacted by a payer should verify its transaction status using the Merchant Portal and either manually complete it or send to the acquiring bank for its refund In both cases the merchant should keep the payer updated about the status There are rare situations when the merchant will receive finalization time out despite the transaction being completed on both the issuer s and even the payment gateway s end If such a transaction was sent in CPT N mode or has been completed only on the issuer side then the payer will not be charged although money paid during transaction can be temporary blocked However if the transaction reached the payment gateway and automatic capture got executed the payer can be charged Both situations should be resolved during reconciliation when the merchant compare its records with the payment gateway records Furthermore the merchant should execute Reversal in case of CPT N done from Merchant Po
46. entication A Merchant logo can be used on this payment portal to identify the merchant 4 Recurrence Model In compliance with PCI standards any non PCI compliant party cannot save Credit Card information So in order to assist Merchants non PCI compliant IPG provides this feature to save payer s Credit Card information in IPG for making recurring transactions in future IPG Features Document Merchant Integration Support 17 a lail etisalat 3 1 Authorization Model Authorization Model refers to the traditional way for making online payments where Merchant seller collects all the credit card related information from his Customer buyer and sends it to the Payment Gateway for processing This model is also adapted for payments where redirection is not an option like POS terminals CAT transactions MOTO transactions and other SPI enabled devices Figure 1 shows the business workflow of a transaction following Authorization Model Traditional Transaction Model Authorization Model Payment Data is shared with merchant payment gateway acquirer and payment scheme air as Ac A Payment Scheme ac Fr Data exchange Payment Gateway E g _ with no payment Merchant server E Pada information y Issuer Lea with sensitive payment information Payer Buyer Figure 1 Authorization Model in IPG can be adapted in two ways 3 1 1 Card Not Present Card Not Present Scenario Introduction Card No
47. er to receive user friendly description of the event please use ResponseDescription field Please refer to FAQ Document for Troubleshooting guide on IPG errors ResponseDescription User friendly description of the error in ResponseCode Note This field can only be used to display the error description and should not be used to check if transaction was successful to check if transaction was successful please use ResponseCode field IPG Features Document Merchant Integration Support 60 ula etisalat ResponseClass This field serves a similar purpose as ResponseCode but instead of giving a very detailed error it specifies at which stage or part of the system request failed for example it may point out that issuer declined request or acquire did not accept it or Payment Gateway rejected it without going into detail ResponseClassDescription This is a user friendly description of ResponseClass Transaction ID Unique ID for in progress transaction Returned in response for every call PaymentPage Link to Common Payment Page where payer will be asked to input Credit Card information for secure transaction Returned only in response for Registration call ApprovalCode This is the response coming from respective bank for Authorization Returned only in response for Authorization amp Finalization calls OrderlD OrderlD as provided by Customer or if Customer chose automated OrderlD gene
48. erchant Integration Support bail etisalat 3 1 2 2 E OS 23 E 24 3 2 Redirection Oe 24 3 2 1 Auto Capture Card Not Present Scenario 25 a e ee EE 25 Implementation EE 26 Pl Cali ia 26 3 2 2 Manual Capture Card Not Present Scenario ooononnccconcccnocnnononanononononnnononn nono nnnononcnonnnos 27 NETO UCA E 27 implementati tisine aier oaee idiota 27 A cuscetessealeaneatadescaseesss caavudevesnutsgncengites tadeessSecawentecanniva versuadsebusnecyuatvedeseaentieven cave casas 29 33 3D Sec re MO dels eege ense e deet ee eebe ee cia 29 Implementar A A AA Ad Di 30 3 4 Recurring Payments Model 30 3 4 1 Step 1 Registering Credit Card for recurring payments ooooccccncnonononnnnnoncnnnnnonnnnoncnnnnnnnnonnnnonoss 31 3 4 2 Step 2 Recurring Payment through Authorization Call or Registration Call 31 3 4 2 1 Option 1 Recurring Payment through Registration Call for a registered Credit Card 31 3 4 2 2 Option 2 Recurring Payment through Authorization Call for a registered Credit Card 32 3 5 Comparison between Manual Capture and Auto Capture 33 A youu saad senaeadeaatesssedubgoaadguderaat aneeadaezaantnavia 35 4 1 Payment Specific DECISION eieiei eenei noeneen OaE AEE an EEE EE SE EEan a EEan EE a EENES EEEREN 36 4 1 1 Web based payments decisions coooocccnonoccccnononnnonononnnonononononono nono non nn nc nnnn nn na nonn nn ra nano nncans 36 4 1 1 1 Integrated Payment Portal 36 4 1 1 2 Merchant pay
49. erminal has to be hit pay Terminal Terminal Name pay Execute 5 1 3 SPIj This section covers SPI implementation for Java based server environments For PHP based servers PHP Java Bridge can be used IPG does not provide any support for PHP Java Bridge or related issues Merchant has to do this on his own Please download SPIj package available at download link provided in section 5 5 1 3 1 System Requirements e Any machine and operating system capable of running java the ability to run graphics applications is recommended but not required IPG Features Document Merchant Integration Support 46 ula etisalat e TCP connectivity to Internet Payment Gateway refer to section 5 1 1 e Java2 Runtime Environment 1 4 x or later no additional components required 5 1 3 2 Installation e Download SPIj package from the Download link provided in section 5 e Unpack zip file to the directory where you plan to have SPIj installed e Add SPI jar file to your java classpath 5 1 3 3 SSL Requirements In order to be able to establish a secure connection to IPG merchant has to poses a client certificate refer to section 5 1 1 3 which is trusted by IPG and allows SPIj to trust the certification authority which issued IPG server certificate The certificates are kept in two different stores SPIMerchant store and SPIMTrust store The first one is client certificate while the second one contains the list of trusted authorities C
50. es e https demo ipg comtrust ae merchant downloads IPGManual pdf e https demo ipg comtrust ae merchant downloads IPGKnowledgeBase pdf e https demo ipg comtrust ae merchant Using Digital Certificate with Merchant Portal permissions provisioned e Plus any user manual for specific SPI version provided with in the SPI download package Assumptions e Use Case 2 has passed successfully Actors e Merchant Steps e IPG will automatically redirect to the ReturnPath provided by Merchant in Registration call e Confirm that TransactionID returned in response is same as received in Registration call e Open https demo ipg comtrust ae merchant using Merchant certificate search for the TransactionID returned open details of transaction and verify that successful Payment Data Update call is in place amount field will be blank in all calls till this phase e Finalization called Issues e Verify that ReturnPath is internet accessible link localhost or local server link cannot be accessed by IPG when IPG would try to redirect for Finalization Comments Incase anything is confusing still getting any issues while making Registration call please contact merchant integration etisalat ae Merchant Integration Support Use Case 4 Capture Reversal on IPG Staging Server Use Case Capture Reversal on IPG Staging Server Description Confirmation that the transaction has been completed successfully Auto Capture Amount captured automatica
51. es Document Merchant Integration Support ula etisalat 1 1 https demo i 1 2 Related Documents comtrust ae merchant downloads IPGKnowledgeBase pdf Glossary of Terms The table below consists of a compiled list of terms that will assist the reader in understanding the jargon used extensively in the field of electronic commerce Terms Description 3DSecure Authentication New system aimed at reducing online credit card fraud and chargeback It enables additional authentication on the cardholder s identity by asking for additional PIN during an online shopping transaction VISA name it Verified by VISA while MasterCard name it Master SecureCode Acquirer The bank which recruits shops and other service providers to accept payment cards Acquirers process a merchant s transactions and pass them into the clearing system to allow financial settlement Authentication The process of verifying the identity and legitimacy of a person object or system Authorization The process whereby a merchant or a cardholder through an ATM requests permission from the Card Issuer for the card to be used for a particular transaction Captured The status of a transaction that has gone through Authorization or Post Authorization and is waiting for settlement Card Issuer The bank or company which issues a payment card to the customer and which has financial responsibility for a card originated t
52. ferent syntax 5 3 8 1 Early bind properties e Customer e Store e Terminal e Language e MerchantKeyStore SPIj only e MerchantKeystorePassword SPIj only e TrustedKeystore SPIj only e TrustedKeystorePassword SPIj only e ConnectionAddress e ConnectionPort e ConnectionTimeout e ConnectionSecure e ResponseCode e ResponseDescription e ResponseClass e ResponseClassDescription All early bind properties can be accessed using the following syntax SPI net A pay NameOfProperty pay NameOfProperty A For example pay Customer ABC Resp pay ResponseCode Connection Related Properties can be accessed using Connection property For example Address pay Connection Address pay Connection Address Address SPIj A Object getNameOfProperty Object setNameOfProperty A For example object setCustomer ABC resp object getResponseCode IPG Features Document Merchant Integration Support 62 cd lail etisalat All properties are strings except ConnectionPort ConnectionTimeout Language ResponseCode and ResponseClass which are of type integer and ConnectionSecure which is a boolean value 5 3 8 2 Late Bind Properties All other properties like TransactionID Amount and Currency etc All late bind properties can be accessed using the following syntax SPI net A pay GetProperty NameOfProperty pay SetProperty NameOfProperty A For example pay SetProperty Am
53. ficates can be downloaded from the following link Download Link https demo ipg comtrust ae merchant downloads IPG Features Document Merchant Integration Support 42 ula etisalat 5 1 SPI Installation Guide 5 1 1 Requirements e Every version of SPI requires specific installation and configuration steps but all share some of system level configurations and tests e It is assumed that runtime environment i e Java for SPIj and net framework for SPlnet has already been installed and configured on Merchant s server machine This guide does not cover any steps related to such configurations 5 1 1 1 Firewall Router Configuration The following outbound connections have to be allowed from the server hosting SPI e IPG Production ipg comtrust ae 195 229 85 91 2443 SSL e IPG Staging demo ipg comtrust ae 195 229 84 29 2443 SSL 5 1 1 2 Connectivity Testing To test the connectivity and router firewall setting applied in the previous step please use the following lines e IPG Production telnet ipg comtrust ae 2443 e IPG Staging telnet demo ipg comtrust ae 2443 The connection on ports 2443 is based on SSL and as such is not fully understood by simple system applications as telnet however it allows confirming the basic connectivity telnet should connect to the port without showing any kind of error like for example connection refused or listener not found NOTE IPG refuses any connections coming from proxy
54. g to particular brands whenever extra security information should be asked for Additionally the merchant will not be able to perform BizDirect nor eDirham payments and their transactions will not be processed in the 3DSecure compliant fashion thus exposing them to liability for any fraud made From a technical point of view the merchant will use a single Authorization call instead of Registration redirection and Finalization calls present in the Payment Portal enabled implementation 4 1 1 3 SPILess Payment In certain situations where the merchant wants to process payments their web server does not allow installing SPI components or the appropriate SPI since such a platform does not exist In these cases merchants may opt to choose the SPlLess payment approach unlike those described earlier This situation is most common in shared hosting environments where the server owner allows only components approved by them to be present on the system Similar situation takes place if outgoing access is not allowed from the system Since most of the SPI versions have to be installed or configured by system administrator and all require outgoing access to connect to IPG such situations make standard processing impossible To allow these merchants to transact online rather than process requests in MOTO mode an additional transaction mode is possible In this mode the merchant rather than sending transaction details to the IPG using SPI component simply
55. hant The organization the Departments of Abu Dhabi accepting credit card payments for the services they provide The term merchant in this On boarding guide will be used to described the role and activities needed to be taken up by the prospective Department of Abu Dhabi interesting in implementing IPG Payment Solutions IPG Features Document Merchant Integration Support 10 cd Lef etisalat Merchant Bank Account Allows an organization to accept credit card transactions from customers Merchant bank accounts are commercial bank accounts set up between an organization and a financial institution Funds from customers are deposited into the merchant account Payment Gateway A computer system that acts as a mediator between a merchant account and online storefront Payment gateway is used in authentication of credit card information and real time charging from a credit card Point Of Sale PoS or Point of Service Location where a customer makes a purchase PoS Terminal An electronic device used to accept and process card payments at point of sale Post Authorization A transaction that puts a Pre Authorization transaction into a Captured state for settlement In the case of partial shipments the Post Authorization amount may be less than the Pre Authorization amount Pre Authorization A transaction type in which a cardholder s account is verified to be in good standing t
56. hat is the card is valid and has not reached its limit If the verifications are approved the total amount of the order is reserved against the cardholder s account balance Pre Authorization is used if goods are to be physically shipped or in other cases for which the merchant must first verify whether the order can be fulfilled An approved Pre Authorization is followed by a Post Authorization which prepares it for settlement Request for information RFI Where an issuer requests an acquirer to supply details of a cardholder s specific transaction undertaken at a point of sale device Secure Sockets Layer SSL It s a protocol designed for secure transfer of Information over the Internet Information sent through an SSL secured form is encrypted so that the information is not tempered with while the transfer is taking place Verified by Visa VbV Verified by Visa is a system used by Visa as an added layer of security for online credit card transactions It relies on a password to validate the transaction This acts in the same way as using a PIN or signature when purchases are made over the counter This will ensure that it is IPG Features Document Merchant Integration Support 11 cd lail etisalat in fact the actual cardholder making the purchase The similar system is used by Master Card under the name SecureCode It is an easy to use password protected online payment verification syst
57. ifferent security requirements and integration processes Redirection Model explained above in detail applies to these kinds of transactions 4 1 1 1 Integrated Payment Portal The most common way for processing web based payment is through the Integrated Payment Portal Merchants using this mode are not required to collect any payment information on their own After receiving the payer s confirmation of purchase intent the merchant will calculate the value of goods and services and register the transaction with the IPG Ifthe registration has been processed successfully the IPG will return transaction identifier TransactionID and URL for Payment Page This identifier can be used for subsequent tracing of the order and the URL of the Payment Portal which in turn is used by the merchant for redirection After redirection the payer will be presented with the IPG Common Payment Portal where he will provide payment details and be guided through the authentication process if required On completion the payer will be redirected to the merchant s website and the merchant will decide if they want to go ahead with transaction If so they can finalize the transaction which will result in either blocking payer funds against transaction requested or funds transferred directly to the merchant s account both can take place only if finalization was successful While the Payment Portal is used by multiple merchants it allows each merchant to customize th
58. iness requires any physical logical business flow does not need any authentication validation like in case you physical logical authentication validation for have to validate a physical delivery address example a retail store or amount has to be captured subject to goods received Done seamlessly and automatically Sometimes need extra manual effort and delegation of a user action if the authentication validation is not automatic in Merchant application IPG closes the transaction itself Merchant is responsible for any captures reversals or what so ever IPG Features Document Merchant Integration Support 34 un lail etisalat 4 IPG INTEGRATION GUIDE IPG provides the merchant with an ePayment Platform Integration tool called Store Payment Interface SPI This will enable the merchant to integrate their website store easily with the payment platform The SPI is a product which sits on the Merchant Server and controls communication between the IPG ePayment Platform and the Merchant Server Before doing the final technical level configurations and integration there several post requisites to be considered and answered which are stated as under IPG Features Document Merchant Integration Support 35 ula etisalat 4 1 Payment Specific Decision 4 1 1 Web based payments decisions For web based payments the merchant can select one of three modes Each mode consists of various features being available d
59. ivacy in addition to the failure of issuers to be able to verify such information across the world The only solution to keep such data private was for the payer to enter it directly onto the issuer website which should be the only party besides the payer who will have such information In this case security of web based payment transactions should be considered similar to the one used while accessing eBanking websites or using ATMs The family of protocols allowing merchant to benefit from such security is commonly called 3Dsecure however different payment schemas use their own names like VbV Verified by Visa SecureCode and J Secure The addition of 3Dsecure protocols significantly improved the security of web based transactions and in the case where the merchants fulfill all the requirements of such a programme they are no longer liable for fraudulent transactions although there are some exceptions to this 2 3 Mail Order Telephone Order MOTO Recurring payment transactions are not constantly initiated by payer and are not in the presence of payer like in case of POS mode Such payments takes place for orders received by phone email mail as well as those where the payer provided his payment details and allowed merchant to charge him periodically e g service payments installments etc While most of original requirement for MOTO transactions can be now supported by the previously explained transaction types call centers and recu
60. ive information E E with sensitive payment information ef ps Pl with extremely H E sensitive information Payer Buyer lt is also possible that merchant collects Payment Data but this require complex functionality to be implemented as part of Merchant website Figure 9 Implementation For the implementation of 3D Secure no settings or configurations has to be done at Merchant s side Merchant bank specifies in Work Order regarding is 3D Secure applicable or not and if it is then configurations has to be done on IPG end during the provisioning process 3 4 Recurring Payments Model Recurring Payments is a solution where a Merchant wants to save Credit Card information sensitive data and payer gives him permission to make future transactions on his behalf or may be on just one click by payer payer does not need to provide same Credit Card information again and again for his future transactions As per PCI standards only PCI compliant companies are allowed to store any Credit Card sensitive data like card number Every merchant who wants to implement Recurring Payments kind of functionality cannot afford to be PCI compliance So IPG is providing Recurring Payments feature where merchants will redirect the payers to IPG where they ll provide their Credit Card details IPG will authenticate provided data and return a reference for saved Card details for future Recurring Payment call from same Merchant for that specific Credit
61. lient certificate can be acquired by following the steps mentioned in section 5 1 1 3 while SPIMTrust is available in SPI download package in Certificates folder password for SPIMTrust store is password 5 1 3 4 Configuration 1 Open SPI properties file 2 Update MerchantKeystore property to reflect the location of your certificate pfx file provided by PKI Pfx file must not include certificate chain refer to section 5 1 1 3 3 Update MerchantKeystorePassword with the password to your certificate Update TrustedKeystore property to reflect the location of SPIMTrust file 5 Make sure that certificate is in proper format it should be password protected and without CA chain to make sure that the format is as described above please import your certificate into any windows system and then export it using following options e With private key e Without certificate chain e Without any additional properties or higher encryption schemes e With password 6 In SPIj Run the test tool provided to make sure the configurations are working fine 8 Sample and test projects files can also be found in SPIj download package IPG Features Document Merchant Integration Support 47 ula etisalat 5 1 4 SPIs Windows Service SPls is a windows service that allows IPG Merchants to communicate to IPG using simple SPI calls This version of SPI is useful especially in cases where implementation of SPInet and SPIj is not an option like in cases of
62. lly SKIP THIS USE CASE Manual Capture Amount has been blocked only Transaction is not closed and is waiting to be captured or reversed and Capture Reversal have been implemented configured properly e Sources e https demo ipg comtrust ae merchant downloads IPGManual pdf e https demo ipg comtrust ae merchant downloads IPGKnowledgeBase pdf e https demo ipg comtrust ae merchant Using Digital Certificate with Merchant Portal permissions provisioned e Plus any user manual for specific SPI version provided with in the SPI download package Assumptions e Transaction had been registered for Manual Capture in Registration call Actors e Merchant IPG Features Document Merchant Integration Support 71 ula etisalat Steps e Open https demo ipg comtrust ae merchant using Merchant certificate search for the TransactionID returned open details of transaction and verify that successful CC Authorization call is in place along with the amount e Merchant will develop a separate page to close the in progress transactions e Merchant has to keep track of open transactions himself and trigger Capture Reversal manually or in code as a separate call e Other way is to pen https demo ipg comtrust ae merchant using Merchant certificate search for the TransactionID open the details of transaction at the bottom of page fields buttons are available for specific action Issues e Transaction registere
63. ment entry page using authorization Ab 36 4 1 1 3 AA Vu 37 4 1 2 le Re 38 4 1 2 1 Standard authorization call 38 4 1 2 2 Customer Activated Terminals CAT 38 4 1 2 3 Recurring ee Eege E 38 IPG Features Document Merchant Integration Support bail etisalat 4 2 Merchant Specific Decdslon ranis d rrara ENN ANENA AEN SAANEN N AANE PAENT 40 4 2 1 Selecting the right capture mode and handling finalization and delivery errors 40 4 2 2 SPI Platformi Selection doaiids 41 4 2 3 Enabling Verification Cod ccccccccssssscecssssececssssececessaeeeesesaececsesaececsesaeeeeseaaececsesaeeseseaaes 41 4 2 4 Enabling 3D Secure Authentication cccccscccesssssecessseeeecseeaececseaaeeeeseaaeceeseaueeeeseqaeeeeeeaaes 41 Su SPHUSER GUIDE vaio dotan arado gie aaaea aaa daages eegent deg 42 Download Like iii ia 42 5 1 SPl Installation Guide com ie btt 43 5 1 1 REQUITO MOE iconos ees 43 5 1 1 1 Firewall Router Configuration cccccccccscccessceessececssecesseecssseeesaececsseceeeeesaeeeesaeceeseeees 43 5 1 1 2 Connectivity Tee bung aere lic 43 5 1 1 3 Digital Certificat sonirosa A ENE ARAO A REO AOO 43 5 1 2 diiniita E T E E E A AS 44 5 1 2 1 System Requirements cai 44 5 1 2 2 Installation alo date aa 44 5 1 2 1 SSU Requirements cuca 44 5 1 2 2 Configuration aca tia 44 5 1 2 2 1 Loading from configurations Te 45 5 1 2 2 2 Manual Configurations cccccccccccccsssssssecececessese
64. n Utility returns Response Code 0 click Create Web Config button and copy the settings into Web config file for your project Sample code can be found in SPlnet download package 5 1 2 2 2 Manual configurations Once Configuration Utility returns Response Code 0 you have to manually provide connection settings and configuration data into the code IPG Features Document Merchant Integration Support 45 und lail etisalat For manual configurations initialize the Transaction object as provided below and use sample code for setting up transaction properties Transaction pay new Transaction false pay Initialize Registration 2 0 Merchant ID from Work Order pay Customer Demo Merchant Initiaizing the connection pay Connection new Comtrust Payment IPG SPInet Connection PG server address pay Connection Address demo ipg comtrust ae Certificate file path for pfx file pay Connection CertificatePath C Demo Merchant pfx Certificate password pay Connection CertificatePassword Comtrust Connection port pay Connection Port 2443 Securing the connection for communication pay Connection IsSecure true Timeout for connection pay Connection TimeOut 120 Payment channel pay Channel Web Language code pay Language en Store do not mention if default store has to be hit pay Store Store Name Store do not mention if default t
65. n of the Customer ID and his digital certificate provided by Etisalat to authenticate the request but this cannot not be done with SPlLess Since IPG Features Document Merchant Integration Support 48 cla etisalat you as the merchant cannot be authenticated you ll need to send the required information check the sample below and therefore you can only block the amount of money from the credit card To actually transfer the money into your account you ll be required to login using the digital certificate to our Merchant Web Interface and capture the money manually As you can see in the sample below the request is just a simple HTML form that can be sent by anyone so the person using the Merchant Web Interface will have to manually check the records on your database and link them to the transactions in the web interface before capturing them Below is the SPlLess sample with the minimum required parameters you can add more parameters such as Order ID and Name etc mentioned in SPI user guide at below downloads page You can use it to test how SPlLess works use the IPG Card 999000000000029 and you can install the Demo Merchant certificate available in downloads page at https ipg comtrust ae merchant Downloads on your machine Then you can login to our staging Merchant Web Interface https demo ipg comtrust ae merchant in staging you ll have to select Demo Merchant from the Customer List and check your test transac
66. nes mentioned inputs parameters of SPI call specific properties 1 Connection Properties Section 5 3 1 2 SPI Specific Connection Properties Section 5 3 2 5 2 1 Registration This is the first call in Redirection Model refer to section 3 2 Merchant is required to provide all the details for the transaction including following mandatory and optional list of properties this list does not include configuration properties settings mentioned in sub sections of 5 1 Property Usage Comments Request Properties Customer Customer ID Please refer to section 5 3 3 for MANDATORY Customer details Store Store Please refer to section 5 3 3 for Store details OPTIONAL Terminal Terminal Please refer to section 5 3 3 for Terminal OPTIONAL details Channel Payment Channel Please refer to section 5 3 3 for MANDATORY Channel details Amount Total amount to be charged MANDATORY Currency Currency in which above mentioned amount is to be MANDATORY charged OrderlD Merchant can use this property to map id for this OPTIONAL transaction w r t his system can also be auto generated please refer to section 5 3 4 for details ReturnPath Specifies the URL a buyer will be redirected back to MANDATORY in case Redirection Model refer to section 3 2 has been adapted OrderName Short description for order MANDATORY IPG Features Document Merchant Integration Support 50 ula
67. ocess and application as card details are entered onto the merchant s systems 4 1 2 2 Customer Activated Terminals CAT Merchants can accept MOTO transactions from the Customer Activated Terminals CAT using the Card Track 2 Data by sending directly in Authorization call If Track 2 Data is being provided for the transaction then no other Credit Card related information is needed to process the transaction 4 1 2 3 Recurring transactions In many cases MOTO transactions are this transaction of recurring type While the merchant could save card details on their system and fire transactions exactly as in standard authorization call there is a way where merchants can completely avoid PCI DSS implications benefit partially from 3D Secure liability protection and extend the list of payment instruments not only credit cards like in two above methods The merchant would need to request payer to pay the first recurring installment while registering using web payment through the Payment Portal The only difference is that during registration the merchant should indicate that the registration is for recurring transaction and eventually specify recurrence attributes IPG Features Document Merchant Integration Support 38 cs lail etisalat After the first payment is completed processed in 3DSecure way the merchant should store the returned TransactionlD as the identifier of the recurrence Subsequently when merchant wants to collect
68. ount 1 23 TxnID pay GetProperty TransactionID SPIj A Object getProperty NameOfProperty Object setProperty NameOfProperty A For example object setProperty Amount 1 23 TxnID object getProperty Transaction D IPG Features Document Merchant Integration Support 63 bail etisalat 6 Configurations and Test Data for Testing in IPG Staging To assist the merchants for doing POC and sending test transactions to integrate IPG with their system following test configurations and test data shall be used IPG Features Document Merchant Integration Support 64 ula etisalat 6 1 Test Configurations Following are staging configuration details for Demo Merchant Server demo ipg comtrust ae Customer ID Demo Merchant Channel Web Store ID n a this property will is not applicable Terminal ID n a this property will is not applicable Currency AED USD QAR or PKR Certificate Demo Merchant included in SPI tool kit can also be downloaded from https demo ipg comtrust ae merchant downloads DemoMerchant Certificates zip 6 2 Test Data Following are staging configuration details for Demo Merchant Test Cards a 999000000000003 b 999000000000011 c 999000000000029 Expiry Month Any valid month Expiry Year Any valid year between 2000 and 2100 Verification Code Any 4 digit number
69. posts them as HTTP Post hidden fields to the SPlLess Portal The portal takes data and internally registers them with IPG before following standard process through Payment Portal At the end when the Payment Portal would redirect the payer to the merchant s web page for Finalization it will redirect the payer to the SPlLess payments which will do finalization on the merchant s behalf Finally the payer can be redirected to the merchant s website if merchant wishes so or be presented with the completion message While the merchant is not expected to install anything on the system the SPlLess payments have certain security drawbacks This security problem lies in the fact that data between merchant and the SPlLess Portal is passed using redirection through the payer browser Even without advanced knowledge the payer can modify the data sent i e decrease transaction amount change currency or modify transaction result To avoid fraud related to such cases the merchant is required to manually review the details of each transaction before capturing it and providing service The SPlLess Payments will stop the merchant from attempting to capture transaction in single step to ensure that manual process is done As a result payment instruments which require automatic capture like BizDirect or eDirham are not available in this mode Fortunately all other benefits of Payment Portal transaction are kept If merchant detects any discrepancy they can simply
70. ransaction Card Verification Code The last three or four digits of a number printed on or just below the signature panel or on the front of payment cards Cardholder A person to whom a payment card has been issued Cardholder Activated Terminal CAT A terminal activated by the cardholder and not supervised by a member of staff on behalf of the merchant May also be referred to as an Unattended Payment Terminal UPT IPG Features Document Merchant Integration Support ula etisalat Card Not Present Scenario A transaction where the merchant does not have physical access to the card e g through telephone mail order or Internet transactions All transactions where a credit card is not physically swiped through a terminal including internet transactions phone transactions or credit card numbers keyed into a terminal virtual terminal fall into this category Card Present Scenario A transaction where the card is presented physically to the merchant Examples are PoS transactions online transactions where Secure Code is presented etc Common Payment Page CPP In compliance with 3D Secure security guidelines IPG provides a common payment portal which can be used by the merchant for redirecting the card holder once he is ready to provide the credit card details The information is then taken by IPG through the Merchant Plug in and passed to the Issuer for Authentication
71. ration in Registration or Authorization call then the generated value Returned only in response for Authorization 8 Finalization calls Balance This is the response coming from respective bank for Authorization Returned only in response for Capture amp Reversal calls 5 3 7 Customer Properties In addition to the standard set of properties which is available in the SP Registration request it is possible to specify a set of customer defined properties NOTE This works for SPI Registration call only Customer properties use the following syntax ExtraData NameOfProperty The first sign of the property name be letter or underscore while the subsequent ones have to be letter digit underscore hyphen or dot The total length of NameOfProperty cannot exceed 48 characters The value of property has to follow the same rules are OrderInfo It is customer s responsibility to make sure that each name is unique if property names are not unique the result is undefined Customer properties can be included in Registration Authorization Reversal and Capture requests Example pay SetProperty ExtraData ShippingAddress Mr John Sheppard P B 3838 Abu Dhabi pay SetProperty ExtraData ContactEmail J Sheppard yahoo comi IPG Features Document Merchant Integration Support 61 ula etisalat 5 3 8 Property types There are two different types of properties and each group is accessed with dif
72. rchant internal workflow Process Response Payment response for the blocked amount Card po lerchant internal workflow Process Buyer Data et credit card info SPI Authorization Complete merchant and credit card data is provided TransactionHint CPT Y redit card Info Merchant and credit card data Process transaction with bank to block the amount Figure 2 3 1 1 2 Manual Capture Figure 3 explains the technical work flow of a Card Not Present transaction with Manual Capture IPG Features Document Merchant Integration Support 19 bail etisalat Redirection Model Manual Capture Buyer Merchant EPG Card holder wants to pay on merchant website Provide credit card info and other validation authentication checks 4 CPP with avai ilable payment options Common Payment SPI Registration CPT N Redirect to Etisalat Page Merchant internal workflow gt gt TransactionHint Registration MM lt Transaction ID Common Payment Page link Process Registration Request Credit card data SPI Finalization lt Redirected to redirection link provided by merchant in SPI Registration call Pull data against Transaction ID and Customer ID Transaction I gt process transaction with bank to block the amount SS Authorization
73. rences or logging only if advised by Merchant Integration Support 5 2 3 Authorization Authorization Model refer to section 3 1 includes only one call if Auto Capture has not been enabled whenever Manual Capture has been mentioned by the Merchant Capture Reversal call is mandatory to complete and close a transaction else capture is done automatically Following are the set of properties used in different modes refer to section 3 1 of this SPI Authorization call Property Usage Comments Request Properties Customer Customer ID Please refer to section 5 3 3 for MANDATORY Customer details Store Store Please refer to section 5 3 3 for Store details OPTIONAL IPG Features Document Merchant Integration Support 52 ula etisalat Terminal Terminal Please refer to section 5 3 3 for Terminal OPTIONAL details Channel Payment Channel Please refer to section 5 3 3 for MANDATORY Channel details Amount Total amount to be charged MANDATORY Currency Currency in which above mentioned amount is to be MANDATORY charged CardNumber Credit Card number MANDATORY 1 ExpiryYear Expiry year of Credit Card please refer to section MANDATORY 1 5 3 5 for format ExpiryMonth Expiry month of Credit Card please refer to section MANDATORY 1 5 3 5 for format VerifyCode Credit Card Verification Code MANDATORY 1 CardTrack2 Card Track2Da
74. rring payments remain major users of this mode MOTO transactions can be further divided to those where payment details are handed to the merchants and those where the merchant processes the transaction without knowing the card number The latter is possible for a recurring transaction and only if certain other conditions are met Such recurring transactions can be used for both regular transactions with fixed amounts classical installments or for ad hoc transaction with variable amounts in which case the merchant benefits from payment gateway card storage 2 4 Cardholder Activated Terminal CAT CAT transaction mode is very similar to the POS mode explained in earlier The key difference is that the CAT transaction is initiated by the cardholder and does not require the presence of a merchant representative Thus it fits well into a kiosk mode where the standalone machine is placed in public place and allows the cardholder to make payments without the usage of Internet and or mobile CAT transactions are applicable to payment cards only and they require additional device magnetic stripe reader to be embedded into the KIOSK itself as the transaction IPG Features Document Merchant Integration Support 15 ula etisalat is made by swiping card rather than entering its details CAT mode is popular for simple services like billing or penalty payments as well in unmanned physical environments i e self service petrol stations 2 5
75. rtal or Refund directly through the acquirer or BizDirect bank Eventually if merchant maintains the payer details they can contact the payer and make a joint decision regarding when to deliver service or reverse refund payment All situations where the merchants were unable to fulfill their part of transaction while the payer was either charged or money on his account has been blocked are referred to as technical failures regardless of whether it occurred on the merchant side or somewhere else BizDirect and eDirham transactions cannot be process in delayed capture mode thus using CPT N will exclude such payment mechanisms from list of available tokens for the payer On the other hand delayed capture should be used for credit card transactions where the delivery of physical IPG Features Document Merchant Integration Support 40 ula etisalat goods is involved or even in the case where a service is being purchased It would significantly simplify the actions to be taken by the merchant in the case of any technical failure 4 2 2 SPI Platform Selection The SPI is available in several flavors to suit the platform of choice of the merchant The SPI also has built in intelligence to take controlled decisions and logic on the information it services The SPI is usually setup with all the parameters for the merchant including the Merchant ID Current versions of SPI include a SPlnet Windows net Component for ASP net and net s
76. section 5 2 SPI Calls for any help and documentation related to above mentioned SPI calls Note Please strictly follow the calling sequence 3 1 2 Card Present Card Present Scenario Introduction Card Present payments are valid where card is present physically and is swiped into the machine Thus it fits well into POS machine transaction or a kiosk transaction where the standalone machine is placed in public place and allows the cardholder to make payments without the usage of Internet and or mobile Card Present transactions are applicable to payment cards only and they require additional device with magnetic stripe reader to be embedded into the KIOSK itself or a POS machine as the transaction is made by swiping card rather than entering its details CAT mode is popular for simple services like billing or penalty payments as well in unmanned physical environments i e self service petrol stations Implementation Merchants can integrate to IPG for a Card Present transaction using SPI can be downloaded from https demo ipg comtrust ae merchant downloads Following are the two implementation models for Card Not Present scenario 3 1 2 1 Auto Capture Figure 4 explains the technical work flow of a Card Present transaction with Auto Capture IPG Features Document Merchant Integration Support 21 und lail etisalat Authorization Model Card Present Transaction AutoCapture SPI Authorization Complete merchan
77. seeeeeescesseseeaeeeseesseesesneaeeeseesseesaea 45 5 1 3 A 46 5 1 3 1 System REGUIPFEMENTS aiii tio 46 5 1 3 2 Installation mai da diana 47 5 1 3 3 SSL RequITe Ee EE 47 5 1 3 4 CONSUL Ee Ee Ge ee ee 47 5 1 4 SPls Windows Sevi ds 48 5 1 4 1 System Requirements seei ae aae E AE EE EEE 48 5 1 4 2 e DIE LL E 48 5 1 4 3 SSL Requirements li 48 5 1 4 4 CONTSUNATION ii iii 48 IPG Features Document Merchant Integration Support bail etisalat 5 1 5 SPlLles it A 48 52 Re ic 50 5 2 1 EN CH e 50 5 2 2 Eladio 51 5 2 3 ien ele en scsi ti a aia 52 5 2 4 A O Ee ee 54 5 2 5 A EE 55 5 3 SPI Transaction Properties ss cscsssc cecccesesanscncesansccee siadecce cada dida CES 56 5 3 1 Connection Properties essieeetogzeeeeisge dee eee Ce Eear EE EEn ER EE REEE E 56 5 3 2 SPI Specific Connection Properties cconococcnonocnncnononnnonononnnonanonnnonanonnncnnnonnnnnnnrnnnncnnrnnnnnnnos 56 5 3 3 Pointot Sale Properties 57 5 3 4 TRANSACTION Properties eeschte geet eko e e de Ee e eh ee e eege 57 5 3 5 Buyer le ee eg TE 60 5 3 6 A A ri nene aE aE EEA vans cedteevanssndeeesnaveessauscues 60 5 3 7 Customer len dE 61 5 3 8 Property CV DCS vincia 62 5 3 8 1 Eatily pindipropertie Seress be ee EE EE 62 5 3 8 2 Late Bind Properties unica aii 63 6 Configurations and Test Data for Testing in IPG Staging ccccsccccesssececeeseceeeesaeeeesesaeeeeeesaeeeeeeaaes 64 SE TEStCONPBUPATIONS g s SeeuEdd geed ege 65 62 KC E
78. stablish a connection DNS name must be specified i e ipg comtrust ae for IPG Production and demo ipg comtrust ae for IPG Staging servers ConnectionPort The port SPI should connect to should be 2443 for SSL connections ConnectionTimeout Connection timeout in seconds 120 300 Note this value is recommended to be 120 or more any value below 120 may result in transaction inconsistency on the slow network or in heavy load conditions ConnectionSecure true false specifies if SSL or non SSL type of connection is used IPG does not support non SSL connection for SPI calls So this property should always be set to true 5 3 2 SPI Specific Connection Properties Property Description Targeted SPI MerchantKeyStore Name of the keystore where the merchant certificate is SPIj stored physical directory path to client user certificate MerchantKeystoreP Password of the keystore where the merchant certificate SPIj assword is stored password for pfx file TrustedKeystore Name of the keystore which contains certificates of SPIj certification authorities which should be trusted by SPI this data will be used to validate Payment Gateway server certificate This file is same as found in SPIj IPG Features Document Merchant Integration Support 56 ula etisalat downloads package in samples SPIMTrust just mention the physical directory path to this file TrustedKeystor
79. t esaia lerchant and credit card data TransactionHint CPT Y Card Holder swaps the card into provided machine Process transaction with bank to block the amount Capture transaction Payment complete lerchant internal workflo Process Response Payment response for the blocked amount Figure 4 IPG Features Document Merchant Integration Support uN lail etisalat 3 1 2 2 Manual Capture Figure 5 explains the technical work flow of a Card Present transaction with Manual Capture Authorization Model Card Not Present Transaction ManualCapture Buyer Merchant EPG Card Holder wants info to pay J Merchant internal workflow Provide credit card Iw Get credit card info Authorization N complete waiting Le Merchant internal workflow redit card Info Process Buyer Data SPI Authorization Complete merchant and credit card data is provided TransactionHint CPT N Merchant and credit card data gt gt K Process Response Payment response Process transaction with bank to block for capture call to be the amount ssent by merchant 5 5 E 3 2 a Merchant wants t Capture Reverse a transaction having amount already blocked Merchant internal workflow Capture Reverse Trans
80. t Present payments take place for orders received by phone email mail as well as those where the payer provided his payment details and allowed merchant to charge him periodically e g service payments installments etc or in the scenario where Merchant wants to receive credit card information from the customer on his web site These transactions can be further divided to those where payment details are handed to the merchants and those where the merchant processes the transaction without knowing the card number The latter is possible for a recurring transaction and only if certain other conditions are met Such recurring transactions can be used for both regular transactions with fixed amounts classical installments or for ad hoc transaction with variable amounts in which case the merchant benefits from payment gateway card storage IPG Features Document Merchant Integration Support 18 from https Implementation Merchants can integrate to IPG for a Card Not Present transaction using SPI can be downloaded comtrust ae merchant downloads demo i 3 1 1 1 Auto Capture Figure 2 explains the technical work flow of a Card Not Present transaction with Auto Capture Following are the two implementation models for Card Not Present scenario Authorization Model Card Not Present Transaction AutoCapture Buyer Merchant EPG Provide credit card info A Capture transaction Payment complete le
81. ta read from card magnetic tape or MANDATORY 2 chip like in case of kiosk devices OrderlD Merchant can use this property to map id for this OPTIONAL transaction w r t his system can also be auto generated please refer to section 5 3 4 for format OrderName Short description for order OPTIONAL OrderlInfo Details of order OPTIONAL TransactionHint It is used to specify which payment instruments OPTIONAL should be available to the buyer Merchant can specify which features should be supported by payment instrument i e Auto Capture Reversal or Manual Capture Reversal By default it is set Auto Capture please refer to section 5 3 4 Transaction Properties for details Transaction ID RecurrencelD for a registered for a Credit Card MANDATORY 3 recurring payments for Recurring Payment Response Properties TransactionID Reference for ongoing transaction to be used in all SPI calls made for this transaction TransactionID should be saved by Merchant for any future references to a particular transaction in IPG system ApprovalCode ApprovalCode as sent by the issuer bank Merchant should save this code for future reference and communication with issuer bank related to a particular transaction IPG Features Document Merchant Integration Support 53 ula etisalat OrderlD It s returned if it s set to be auto generated NOTE Please make sure to send either
82. tandalone applications may also work on non Windows platforms where flavors of Net framework exists b SPIj Any platform running Java Java application servers and java applications java can be also run inside of non java based servers i e PHP c SPI Windows Service SPls is a windows service that allows IPG Merchants to communicate to IPG using simple SPI calls d SPlLess No SPI installed on the merchant server HTML page redirected to a hosted page Automated capture not possible with this option Capture can be done manually through a Web User Interface 4 2 3 Enabling Verification Code By default Card Verification Code is not required to make a transaction If merchant wants it to be required a property called TransactionHint has to be configured during SPI Registration call Please refer to section 5 3 4 Transaction Properties for details on TransactionHint 4 2 4 Enabling 3D Secure Authentication For accepting payments using 3D secure merchant needs to contact their bank bank provides the details for 3D secure in the Work Order to IPG There are no specific configurations needed on merchant side to process payments using 3D secure authentication IPG Features Document Merchant Integration Support 41 un lail etisalat 5 SPI USER GUIDE This section points to SPI installation configuration and troubleshooting guide with API for SPI calls SPI along with samples configuration tools and test digital certi
83. the following payments they should conduct authorization but instead of specifying payment details which they do not have they should give the previously obtained TransactionID If the merchant specified any recurrence attributes the payment gateway will further verify if the requested transaction does not violate any of them Using this method imposes certain requirements on merchant process thus it cannot be used in all cases as registration has to be made through the channel which is supported by Payment Portal In addition the first transaction has to be executed during registration although this could be just a token value transaction reversed in case of success IPG Features Document Merchant Integration Support 39 ula etisalat 4 2 Merchant Specific Decision 4 2 1 Selecting the right capture mode and handling finalization and delivery errors The merchant should select the capture mode automatic or delayed based on the type of service sold If the merchant is selling physical goods or there is a possibility that the requested service cannot be delivered the merchant should select delayed capture TransactionHint CPT N and execute the capture separately after fulfillment N B does not include transactions done using BizDirect eDirham payment methods If the merchant decides to use immediate capture CPT Y they should be able to handle situations such as the inability to update their systems or a temporary fulfillm
84. tions use the Not Captured report to find transactions with block amount only also note that many other customers are testing using Demo Merchant on our staging system so you ll find transactions not related to you lt html gt lt body gt lt form method POST action https demo ipg comtrust ae SPlless Registration aspx gt lt table gt lt tr gt lt td gt Amount lt td gt lt td gt lt input type text name Amount value 99 98 gt lt td gt lt tr gt lt tr gt lt td gt Currency lt td gt lt td gt lt input type text name Currency value AED gt lt td gt lt tr gt lt tr gt lt td gt Customer lt td gt lt td gt lt input type text name Customer value Demo Merchant gt lt td gt lt tr gt lt tr gt lt td gt Language lt td gt lt td gt lt input type text name Language value en gt lt td gt lt tr gt lt tr gt lt td colspan 2 gt lt input type submit value Pay gt lt td gt lt tr gt lt table gt lt form gt lt body gt lt html gt IPG Features Document Merchant Integration Support 49 ula etisalat 5 2 SPI Calls In reference to Payment Models refer to section 3 following are the details for IPG calls that a merchant can make using SPI Please find the detailed usage and documentation of properties used in SPI Calls in following section i e section 5 3 NOTE Following sections are common and mandatory inputs parameters to every SPI call other than the o
85. ument Merchant Integration Support 32 ula etisalat storing it Following parameters needs to be added to identify that call is treated for already registered recurring payment Parameter Value TransactionID RecurrencelD returned by SPI Finalization call in STEP Section 3 4 1 Following things must be noted or considered once SPI Authorization call is identified as a recurring payment call e Each call will automatically get and use the Credit Card details saved during registration e Payer will not be prompted again for any authentication e This subscription for recurring payments will stay valid till Credit Card expiry date e Any details for a registered Credit Card cannot be changed e A new and unique TransactionID will be returned as a reference against each SPI Authorization call please don t confuse and or replace Subsequent Recurring Transaction with the Original Registration Transaction NOTE This is a non 3D mode of recurring payments even if the Original transaction is 3D secure this doesn t mean merchant is protected for the subsequent transaction Each transaction is a separate transaction in itself and therefore liability applies individually 3 5 Comparison between Manual Capture and Auto Capture Auto Capture Manual Capture Technical Differences In SPI Registration call TransactionHint In SPI Registration call TransactionHint property has a value
86. with 3D Secure security guidelines IPG provides a common payment portal which can be used by the merchant for redirecting the card holder once he is ready to provide the credit card details The information is then taken by IPG through the Merchant Plug in and passed to the Issuer for Authentication A Merchant logo can be used on this payment portal to identify the merchant The Merchant can modify design fonts color scheme of the Payment Portal to make it appear to be a part of the merchant s website 3D Secure is the most secure payment method available for payment In addition to the steps mentioned in Redirection Model after Card validation on CPP IPG looks for 3D Secure URL provided by the card issuer bank and opens the bank s 3D Secure URL in a pop up This page has been hosted by the bank itself and buyer provides the information like PIN or Password that s already been communicated to the buyer by his bank If authenticated response is given back to CPP and CPP redirects back to Merchant s redirection link for Finalization and other steps to complete the payment Figure 9 shows the business workflow of a transaction following Redirection Model IPG Features Document Merchant Integration Support 29 un lail etisalat 3DSecure Transaction Model 3DSecure data i e PIN shared only with issuer fin uf Shopping Cart Payment Scheme e N Key Data exchange y e y J ET with no payment S sensit

IPG Manual - IIS Windows Server

Contents

Download Pdf Manuals

Related Search

Related Contents