PaymentSITE is a hosted payment page that can be integrated into a merchant’s system to process payments. Upon accessing the PaymentSITE, either where it is embedded or via a standalone URL, the customer can enter their payment details and any other relevant information like their name, address, and phone number. PaymentSITE tokenizes all card data and keeps the merchant out of scope for PCI compliance.
The most popular form integration flow for developers is to build their own secure form with iFields for the user to enter their information, and then submit the transaction via our Transaction API. By doing so, the developer maintains full control over the UI and behavior of the integration. When using a PaymentSITE, the developer gives up much control and is limited to whatever is supported by PaymentSITE.
The advantage of PaymentSITE is that it is a quicker and easier implementation since the developer does not need to build the secure payment form and API calls directly. In addition, the user can utilize PaymentSITE’s built-in features and customizations without the developer needing to do additional work.
The PaymentSite can be configured to process various different payment types:
Save. For more details on what each of these commands is used for see Transaction API
The PaymentSite is implemented so that when the user is ready to pay, they are redirected out of the merchants system, to the PaymentSite to enter their payment information.
When the user is ready to pay, the PaymentSite is opened in an iFrame in the merchants system.
Most fields that are on the PaymentSite (besides the sensitive payment details) can be pre-populated by the merchants system before the user is directed to the page. This can be done by specifying the “key” and “values” of those fields separated by the “&” symbol in the URL query string. The “key“ value needs to match exactly the html “name“ element of the field; you can find that by inspecting the page using the developer tools of a browser. You can also look at the Transaction API by transaction type to find most fields.
Note: The merchant can log into the Cardknox portal to control what fields are available on the page. If you try to pre populate a field that is not added to the page, the system will just ignore it.
Here is a list of specific settings fields that can be set in the query string in addition to the above.
This is the URL that the page will be redirected after the user submits the payment and the transaction is approved. If this is not specified, the user will stay on the PaymentSITE page and receive a message that the payment went through successfully.
This is the URL that the page will be redirected after the user submits the payment and the transaction is not approved. If this is not specified, the user will stay on the PaymentSITE page and receive a message that the payment did not go through, and they will be able to try again
This is the URL the webhook will be sent to after the user submits the payment.
Accounts need a setting enabled by a Cardknox Support Team member to use the
Typically, after the transaction is completed by the user, the PaymentSite will automatically redirect the user back to the merchants system. There are two ways how to specify the redirect URL
- 1.Set the Redirect URL in the Cardknox PaymentSite backend settings
- 2.Set the
xRedirectURLparameter in the query string when directing the user to the PaymentSITE.
The redirect will return the response parameter in the redirect quarry string. For a full list of response fields see Response parameters
The merchant's site can be notified of transaction responses via webhook notifications. This can be implemented in one of several ways:
- 2.Set the webhook URL in the Cardknox PaymentSite backend settings
- 3.Set the
xPostUrlthe parameter in the query string when directing the user to the PaymentSITE.
To set an
xPostUrl, please note that you need to contact Gateway Support to enable the setting for this method to function correctly.