By default, during the payment form submission, the st.js will automatically tokenise sensitive payment details to create a unique cachetoken. The cachetoken is used to represent the payment details.
However, if you have obtained the necessary PCI certification to process and submit sensitive cardholder data, and have access to the unencrypted card details prior to processing a payment, you can have these submitted to your server directly rather than using a cachetoken by following the steps below:
Overview
- Capture the required card details (and other optional details) using your own checkout form.
- On submit, this first form will POST to an intermediary page that hosts our mark-up. This is effectively a holding page that is temporarily shown before the customer is displayed the ACS page within a pop-up and/or redirected to your success page.
We recommend displaying a loading animation and/or message in case the JS takes more than a couple of seconds to complete the request.
- If enrolled in 3-D Secure, the customer’s browser may display an overlay, where they are asked to complete some basic actions to authenticate their identity.
- Following any checks and authentication required by the customer’s card issuer, the overlay will close automatically, and the payment will be processed. Following this, the checkout will display a success message to the customer.
Modify the server-side payment form
Please ensure you have read and understood the overview above before proceeding. This section only applies to merchants who have obtained the necessary PCI certification to process and submit sensitive cardholder data.
You will need to host a form on the intermediary page that loads the sensitive data into a JWT and submit this to Trust Payments, as described below.
startOnLoad
You must ensure your form includes the additional field startOnLoad within st.Components, with value “true”. This negates the need for customer interaction for the form to submit the data to Trust Payments.
submitOnError
You must ensure your form includes the additional field submitOnError, with value “true”. This ensures that if an error occurs, the customer will be redirected to your website so they can amend their details and retry the payment.
jwt
Refer to this page to learn how to construct the JWT (JSON Web Token). In this alternative workflow, the JWT must also include the pan, expirydate and securitycode fields, as shown in the example below:
{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"currencyiso3a":"GBP",
"sitereference":"test_site12345",
"requesttypedescriptions":["THREEDQUERY","AUTH"],
"pan":"4111111111111111",
"expirydate":"12/2031",
"securitycode":"123"
},
"iat":1559033849,
"iss":"jwt.user"
}
Form
Unlike in the other examples we provide, the form in this configuration doesn’t need to include fields requesting the card details, because these have already been included in the JWT.
The form also doesn’t need to include a submit button, because startOnLoad will submit the contents of the form automatically, including the JWT.
<html>
<head>
</head>
<body>
<div id="st-notification-frame"></div>
<form id="st-form" action="https://www.example.com" method="POST">
</form>
<script src="https://cdn.eu.trustpayments.com/js/latest/st.js"></script>
<script>
(function() {
var st = SecureTrading({
jwt:'INSERT YOUR JWT HERE',
submitOnError: true
});
st.Components({startOnLoad: true});
})();
</script>
</body>
</html>
Logging considerations
When using the startOnLoad payment flow, the gateway response will include the request JWT (in the “jwt” field) containing the submitted sensitive card details. For this reason, you must ensure that these sensitive payment fields (such as the pan, expirydate and securitycode) are masked or excluded when logging to your records, in order to adhere to PCI compliance.
