| Property | Description | Default value |
|---|---|---|
|
This represents the number of failed API interactions that can occur with the Orbital Gateway before the service is considered to be 'down'. |
1 |
|
The set of transaction types that the gateway integration supports. |
|
|
The set of features that the gateway integration supports. |
|
|
The gateway type key to use in Broadleaf when targeting the Orbital gateway integration. |
|
|
The name of the Payment attribute that the transaction reference ID should be saved as, mapped by transaction type. |
|
These properties configure the behavior of the HPSProvider component, which interacts with Chase’s HPS API.
| Property | Description | Default value |
|---|---|---|
|
The base URL at which the Chase Hosted Payment Solutions API is located. The default value is the HPS 3.0 Testing Environment. |
|
|
The relative path for the UID Init API operation. |
|
|
The relative path for the UID Query API operation. |
|
|
The relative path at which a frontend can provide the UID and request the actual HPF form (ex: in an iFrame). |
|
|
Note
|
These properties are context-discriminated, and thus each property value can be overridden at the tenant/application level via broadleaf.chase-payment.hps.provider.discriminated.{app or tenant ID}.{property name}
|
| Property | Description | Default value |
|---|---|---|
|
Each HPS profile will be associated with a 'SecureID'. Secure ID starts with 'chs' followed by random numbers. Secure IDs in the testing environment end with 'sb'. This is a secret value that must be included in certain API requests. |
none |
|
The API key (AKA API token) that can be used to access the HPS API. This is a secret value that must be included in certain API requests. |
none |
|
The transaction type that should engage upon HPS submission. This should almost always be left at the default. |
|
|
The name of the pre-configured HPF form in HPS that should be requested. |
none |
|
Defines a whitelist of form names that can be requested in the UID init endpoint. If provided, the requested form name must be a member of this whitelist. This prevents an API caller from being able to request/use any arbitrary form name configured in Chase HPS. |
none |
|
Maximum number of times a customer may receive an error on the hosted page/form and be allowed to retry. When unspecified, the default from HPS is 5. |
none |
|
This is the CIT/MIT message code categorizing the type of transaction that will happen upon HPF/HPP submission. This should almost always be left at the default. |
|
|
Overrides the |
none |
|
Overrides the |
none |
|
Overrides the |
none |
|
Note
|
These properties are context-discriminated, and thus each property value can be overridden at the tenant/application level via broadleaf.chase-payment.hps.validation.discriminated.{app or tenant ID}.{property name}
|
| Property | Description | Default value |
|---|---|---|
|
By default, when the HPS init request is initially made, our backend will track a minimal representation of the ContextRequest in the HPS metadata. After the customer submits the HPS form/page, the next step is typically to create a BLC Payment object with the results. When this flag is enabled, at BLC Payment creation time, the backend will verify that the recorded ContextRequest information for the HPS interaction matches the context that the BLC Payment is being created in. This ensures an HPS profile created for a different application/tenant cannot be used to create a BLC Payment in a different application/tenant. When this flag is disabled, that verification is skipped. |
|
|
By default, when the HPS init request is initially made, our backend will track a minimal representation of the intended payment owner type and payment owner ID in the HPS metadata. After the customer submits the HPS form/page, the next step is typically to create a BLC Payment object with the results. When this flag is enabled, at BLC Payment creation time, the backend will verify that the recorded payment owner information for the HPS interaction matches the payment owner information that the BLC Payment is being created for. This ensures, for example, that a profile created for cartX cannot be used to create a payment for cartY. When this flag is disabled, that verification is skipped. |
|
These properties configure the behavior of the OrbitalGatewayProvider component, which interacts with Chase’s Orbital Gateway JSON API.
| Property | Description | Default value |
|---|---|---|
|
The feature version of the Orbital API to use. This value should only be changed cautiously. |
|
|
If enabled, then API requests will target the primary base API URL. Otherwise, API requests will target the secondary base API URL. This can be useful for system administrators to change the destination of API requests in case of an outage with the primary URL. |
|
|
The primary base URL at which the Chase Orbital API is located. The default value is for the integration testing environment. |
|
|
The secondary base URL at which the Chase Orbital API is located. The default value is for the integration testing environment. This can be used as a failover in case the primary URL is unavailable. |
|
|
The relative path for the create payments operation. |
|
|
The relative path for the capture operation. |
|
|
The relative path for the refund operation. |
|
|
The relative path for the reversal operation. |
|
|
Note
|
These properties are context-discriminated, and thus each property value can be overridden at the tenant/application level via broadleaf.chase-payment.orbital-gateway.provider.discriminated.{app or tenant ID}.{property name}
|
| Property | Description | Default value |
|---|---|---|
|
The Orbital Connection Username to use to authenticate with the Orbital API. |
none |
|
The Orbital Connection password to use to authenticate with the Orbital API. |
none |
|
The Merchant ID that should be used when executing transactions. |
none |
These are properties configuring how response codes from the Orbital Gateway are categorized and mapped in Broadleaf.
| Property | Description | Default value |
|---|---|---|
|
Orbital response code values which should be considered 'hard' declines |
Please review the default values in |
|
A map from Orbital response code values to the |
Please review the default values in |
|
A map from Orbital procStatus values to the |
These are properties used to map a card brand value from the Orbital Gateway to a more generic/commonly understood term in Broadleaf.
| Property | Description | Default value |
|---|---|---|
|
Keys in this map should be the card brand values returned from the Orbital gateway.
Values should be the user-friendly card-type value for that brand which can be used in places like |
Please see |
These are properties configuring Level 2 data settings when using the Orbital Gateway.
| Property | Description | Default value |
|---|---|---|
|
A map keyed from the card brand known by the Orbital gateway to whether Level 2 data will be included in transactions for it (when the card is a commercial card). If a value is not found in this map, Level 2 data inclusion will be assumed to be enabled. |
Please see |
See the Apple Pay properties configured under the Apple Pay section.