Understanding the Integration

The platform allows software companies to integrate electronic payments online, in-app and in-person.

The Key Capabilities of the platform are as follows:

There are two integration methods available: Hosted Payment Page (HPP) and Direct/HTTPS POST (XML). You can use one or a combination of both of them as required, but you should consider the integration method carefully before starting any development planning. If you need assistance with determining your integration method(s), please reach out to support@integratedcommerce.io.

The information below can help you decide on the most appropriate approach. Different technologies, languages, industries, server environments and other technical considerations will be addressed.

Hosted Payment Pages (HPP) enables developers to quickly and securely add credit card acceptance to their websites: the pages are hosted on a secure server. The appearance of the Hosted Payment Pages can be easily customized to look just like your site.

Benefits of the HPP method:

• Ease of integration: As opposed to other integration methods, the HPP integration is VERY simple. Just submit a simple web form and then display the response that is sent back.
• Reduction of PCI scope: By using the HPP method to process payments, card information will never be stored or appear in logs.
• Tokenization: In addition to accepting credit cards, the HPP method also supports storing customer card information securely as a token. This feature is called Secure Card. Those tokens can then be used later for "card on file" transactions such as "sale", "refund" and "subscription". The HPP method also includes a hosted page for customers to securely update their stored card information.
• Everything under one roof: To enable features when using the Hosted Payment Page such as eDCC (Dynamic Currency Conversion), Mobile Payments etc., there is no extra development. These are simple configuration changes and your customers will then be offered the new feature(s).
• iFrame Supported: If you do not want the customer to leave the browser-based software, the HPP can be implemented within an iFrame.

Using the XML method rather than the HPP method would be applicable mainly for custom integrations or highly customized websites. The XML method offers full access to all of our products and methods. Customers using software that solely utilizes the XML method to process or collect credit card data must maintain their own security and are subject to a more rigorous PCI security assessment.

Benefits of the XML method:

• Access: All features and functionality are available when using the XML method. For example, processing a payment, registering credit card information for secure storage (Secure Cards aka Tokens), setup a recurring payment, check the status of existing subscriptions or refunding a customer.
• Software integration: If you would like to tightly integrate card processing into your software, then the XML method is the way to go. For example, you can store credit cards securely for returning customers so that they don't have to put their card details in each time, or display the status of a customers' subscription to your product, etc.

The Direct/HTTPS POST (XML) method can be used to supplement the Hosted Payment Page (HPP) method depending on the feature set being utilized by the developer.

An example use-case would be Card-On-File (token) payments: a developer could utilize the HPP method to process a card payment and also store the card as a token. Then the developer would use the XML method to submit a payment using the token at a later date.

Benefits of using both methods:

• Quick & Secure Integration: Use the HPP method to quickly and securely add card processing (Payments and Pre-Authorizations), token storage and update capabilities, subscription capabilities, etc. to your software.
• Access to additional features: Use the XML method to leverage additional capabilities not available in the HPP method such as Card-On-File (token) payments, Pre-Auth Completions, Refunds, etc.

The public accounts can be used to test basic payment gateway functionality. These accounts (one per currency) are publically available and can be used without requesting access. The public sandbox accounts do not include access to the Selfcare System (Merchant Portal). These accounts are useful for proof-of-concept testing or scoping a payment gateway integration. The public accounts can be found here.

A full test account is used to test and integrate all payment gateway funtionality and includes access to the Selfcare System (Merchant Portal). Integrators will need to utilize a full test account when integrating, testing and certifying their integration. You may request a full test account by contacting support@integratedcommerce.io.

Once you have completed your integration, completed the testing outlined in the Testing Guide and prior to your first merchant being able to process live transactions, we require that your Payment Gateway integration be certified to ensure a smooth go live. The process is as follows:

1) Test your integration thoroughly. Details and guidelines for testing are found in the Testing Guide.

2) Download the ISV Validation Procedure document.

3) Using your full test account, supply at least TWO successful transactions per transaction type that you intend to use. Please refer to the functionality checklist in the ISV Validation Procedure document. Two transactions are necessary to ensure consistency when our support team analyzes your transactions. Record all pertinent information relating to the testing and return the completed document to support@integratedcommerce.io.

4) The support team will review the PDF and contact you to confirm that you have successfully validated against the Payment Gateway. Once confirmed, you will be provided with the live gateway URLs.

Our platform supports embedding the merchant application in your browser-based software. Contact support@integratedcommerce.io for more information.