Each type of integration and each feature may require different settings to work under an integration. Here we are going to review the main settings you have to be aware of before you can start using your integration.
When a Terminal is created or edited, a few permissions need to be set in place so it can operate with HP and its features, and before you can use this integration method, be sure these configuration are in place. Confirm with our support team if the Terminal you are trying to use allows the use of Hosted Payment Pages.
The present settings are to be performed by the Gateway Administrator - verify it before integrating.
The Hosted Page integration method provides some additional settings regarding styling. This allows the pages to be highly styled, so they look more appealing to customers, besides helping to improve conversion rates and customers overall experience.
The configuration regarding this styling can be found at %Selfcare System, under “Settings > Pay Pages”. There you can find templates for your hosted pages and see how they are going to appear to the customers.
For more information about the styling of Hosted Pages, visit the Pay Pages page in our %Selfcare Guide.
The present settings are to be performed by the Merchant.
When a Terminal is created or edited, a few permissions need to be set in place so it can operate with XML Integration and its features, and before you can use this integration method, be sure these configuration are in place.
Your Terminal does not need any special configuration to start using the XML Integration, but depending on the transactions you intent to process using this Terminal, settings must be adjusted. Confirm with our support team if the Terminal you are trying to use allows the use of XML Integration.
A few features demand some configurations to work. Most of them are configured at Terminal Level, and you need to ensure they are accessible to the Terminal you are using. Below, we present a few mentions related to that, but depending on the features you are implementing, the setting might require other checkings, and in this case, contact our Support Team.
The present settings are to be performed by the Gateway Administrator - verify it before integrating.
Merchant Portfolio Settings
At this level, when a Merchant Portfolio is configured, three different settings can be used to define how the the Secure Token Registration and the Payment using a Secure Token should occur for its Merchants:
Merchant Settings
Any merchant can choose between sharing its Secure Tokens among all of its Terminals, or not, using the following property:
However, if the Merchant is associated to a Merchant Portfolio with Enable Token Auto Sharing enabled, its Share all Secure Tokens is automatically enabled.
Terminal Settings
The most basic configuration required to use Secure Token features is the enabling of this feature at Terminal Level.
SHARING AND REUSING Secure Tokens FROM DEACTIVATE TERMINALS
In case a Merchant has deactivated terminals, the Secure Tokens registered on it, by default, won't be available from the moment the terminal is deactivated onward. To avoid that a “Share Secure Tokens from deactivated terminals” feature was introduced, and can be enabled at Merchant Portfolio or Merchant level, when using one of the mentioned sharing options for Secure Tokens.
In case you have deactivated terminals with Secure Tokens and want to reuse them, contact our support team.
First of all, the Subscription feature requires the enabling of the Secure Token features to be used (and actual Secure Tokens registered).
Secondly, the Subscription feature itself needs to be enabled and the following items need to be informed.
| FIELD | DESCRIPTION |
|---|---|
| Subscription max wait for payment, days | Defines the amount of days a subscription's payment can be delayed before the system suspends the given subscription. |
| Subscriptions max missed periods | Defines the amount of times a subscription can miss payments before being suspended by the system. |
| Subscriptions payment notification, days | Defines the amount of days the system waits until sending the notification warning for a subscription which couldn't be paid. |
| Subscription missed periods notification | Defines the amount of times a subscription can miss payments before the system starts sending warning notifications about it. |
| Subscription repeat notification, days | Defines the amount of days the system waits until sending the next notification warning about a subscription which is still not paid. |
| Subscription auth max attempts | Defines the amount of authorization attempts the system will try before suspending an automatic subscription. |