SHC - Secure Hosted Checkout

SHC - Secure Hosted Checkout

Secure Hosted Checkout

What is Secure Hosted Checkout?

Secure Hosted Checkout allows you to redirect customers to a PayFacto-hosted payment page, reducing your PCI compliance scope.

Secure Hosted Checkout (SHC) is a JavaScript library that allows merchants to collect and send cardholder information to PayFacto for authorization (pre-authorization), purchase, or verification without needing to access that information directly. When called, SHC will verify the card information and provide the merchant with a token that can be used for future transactions.

  1. Include the Secure Hosted Checkout library in your webpage
    (i.e.: script src="https://uat.ca.shc.payfacto.cloud/secure-hosted-checkout/v1/browser/shc.js"></script>).
  2. Add a div tag where you want the iframe to appear (i.e. <div id="shc-fields"></div>).
  3. Acquire an SHC token by calling the https://uat.ca.shc.payfacto.cloud/secure-hosted-checkout/v1/sessions endpoint from your server application.

A fully functional example application can be found in our public Bitbucket repository.

What you Need for SHC

Preparing to use SHC

What you Need to Get Started


A merchant will need the following information to get started:

  • An API Key

This information listed above is provided to you when you create a new developer account with PayFacto.

Secure Hosted Checkout Flow


Calling SHC

Putting SHC into action

Calling Secure Hosted Checkout

Calling SHC is a two step process:
  1. A Secure Token must be obtained by calling the /secure-hosted-checkout/v1/sessions endpoint.
  2. After obtaining the token, it must be passed to the shc function which will display the fields for the cardholder to fill in.

Why a Two Step Process?

The first step, calling the /secure-hosted-checkout/v1/sessions endpoint, requires secret information that could be stolen if it was available to the client application. The call to /secure-hosted-checkout/v1/sessions should be done by the merchant’s server, with the result passed to the client.

Examples


InfoNote: All the examples provided use JavaScript.

Obtaining an SHC Token for SHC

SHC tokens are obtained by having the merchant’s server call the shc.titan.uat.ca.payfacto.cloud/secure-hosted-checkout/v1/sessions endpoint. This endpoint is RESTful in that it expects a JSON object as input and returns a JSON object as output. An example of a request is given below:

javascript
javascript
const endpoint = 'https://uat.ca.shc.payfacto.cloud/secure-hosted-checkout/v1/sessions';
const payload = {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Accept': 'application/json',
'Access-Control-Allow-Origin': '*',
'Authorization': `Basic ${apikey}`
},
body: JSON.stringify({ transactionType:'VERIFY' })
};

fetch(endpoint, payload)
.
then(response => response.json())
.
then(response => console.log(response))
.
catch(response => console.error(response));
 

Displaying the Fields on the Screen

The fields for the cardholder to fill in are created and displayed when the shc function is called. The secure token is retrieved from the merchant server and passed to the shc function. The callback, the second argument passed to the shc function, is a merchant defined function that gets the results of the credit card validation and decides what action to take.
  1. merchantGetShcToken(shcToken => { shc(shcToken, response => merchantProcessResponse(response)) });

SHC Responses

After calling SHC, the response guides you to the next step

SHC Callback Response Object

When shc is called it is passed a callback to accept the results of the transaction. When the validation is successful the resulting object looks like the following example:
javascript
javascript
{
success: true,
response: {
authCode: "426186",
avs: "U",
brand: "Visa",
card: "411111******1111",
cvv2Cvc2Status: "M",
email: "test@example.com",
expiry: "1226",
invoiceNumber: "abc-123",
isoResponseCode: "00",
issuerMessage: "AP",
lastFour: "1111",
name: "Test Card",
processorAvsResultCode: "",
purchaseAmount: 1025,
purchaseCurrency: "CAD",
purchaseDate: "2026-01-26 17:47:44 EDT",
secureId: "34fd08eb-cdf4-42bb-983d-ef0a386ce856",
status: "SUCCEEDED",
store: {
address: "123 Some Street, Toronto, ON, A1A 1A1, CA",
email: "contact@merchant-store.com",
name: "Merchant Store",
phone: "(123) 456-7890",
website: "www.merchant.com"
},
success: true,
token: "5k46v51j238tpt5v7v4u4a18hc4f04m9926",
transactionId: "da5a34e0-793c-4c21-9fb2-f03b670eb2f8",
transactionType: "PURCHASE",
type: "CREDIT"
},
metadata: {
algorithm: "sha256",
HMAC: "3f7878f6b6e5e5f4e5d6c7b8a9b0c1d2e3f4g5h6i7j8k9l0m1n2o3p4q5r6s7t8",
timestamp: "2024-06-01T12:47:44Z"
}
}
The contents of the response will vary depending on the operation being performed and the setup of the account.
Below is a list of properties that may be returned:
    1. success: boolean indicating success or failure of the transaction
    2. authCode: the authorization code
    3. avs: the AVS response code
    4. brand: card brand
    5. card: the partial number of the card for display purposes
    6. cvv2Cvc2Status: the CVV response. Valid values are ‘M' for PASS and 'N’ for FAIL
    7. email: the cardholder's e-mail address
    8. expiry: expiry date of the card
    9. invoiceNumber: passed invoice number. If no invoice number is passed then one is generated on the fly
    10. isoResponseCode: ISO response code from issuer
    11. issuerMessage: message from the issuer
    12. lastFour: last four digits of the card number
    13. name: cardholder name
    14. processorAvsResultCode: the AVS response code returned from the processor. Value varies by card brand and processor
    15. purchaseAmount: the amount of the transaction
    16. purchaseCurrency: the currency used to conduct the transaction
    17. purchaseDate: the date and time stamp when the transaction was processed
    18. secureId: the session ID
    19. status: PayFacto payment platform status message
    20. store.address: store address as single line
    21. store.email: store support contact e-mail address
    22. store.name: name of the store the merchant account is associated with
    23. store.phone: store support contact phone number
    24. store.website: store Website
    25. token: card token automatically generated as part of the process
    26. transactionId: the unique identifier of the transaction that was created
    27. transactionType: the type of requested transaction. Valid values are 'PREAUTHORIZATION', PURCHASE, and 'VERIFY'
    28. type: card type. Valid values are CREDIT' and 'DEBIT'
    29. algorithm: the algorithm used to generate an HMAC
    30. HMAC: the contents of the response converted to a string and then encrypted using the sha256 algorithm and the merchant account's private API password
    31. timestamp: the time the transaction was generated.
    32. receipt: an HTML receipt that can be displayed on the screen or embedded in an e-mail

AVS Response Codes

SHC returns a subset of the AVS codes. 

A
Street address matches, ZIP/postal code does not
M
Street address and ZIP/postal code match
N
Street address and ZIP/postal code do not match
U
Address information is unavailable or AVS is not supported by downstream provider
Y
5-Digit ZIP and street address match
Z
5-Digit ZIP matches, street address does not

The Error Response

Sometimes, things don’t go as expected. When that happens, an error is returned to the calling object. The error object resembles the following example:
javascript
javascript
{
success: false,
response: {
code: "INVALID_NUMBER",
message: "card number is incorrect",
type: "CARD_DECLINED"
}
}
 The error response definitions are:
  • code: the subclass of error that was returned. The valid values are
    • INVALID_EXPIRY_DATE
    • INVALID_NUMBER
    • TOKEN_EXPIRED
  • message: A message that briefly describes the nature of the error.
  • success: A boolean value indicating if the request was successful or not. This property will always be set to false for an error response.
  • type: The class of error that was returned. The valid values are:
    • CARD_DECLINED
    • INTERNAL_ERROR
    • UNAUTHORIZED

HTTP Code
Error TypeError Code
400
CARD_DECLINED 
INVALID_CARD_NUMBER
400
CARD_DECLINED
AVS_DECLINED
400
CARD_DECLINED
CARD_BRAND_NOT_SUPPORTED
400
CARD_DECLINED
CVV_DECLINED
400
CARD_DECLINED
RISK_DECLINED
400
CARD_DECLINED
ISSUER_DECLINED
400
AMOUNT_DECLINED
AMOUNT_TOO_LARGE
400
AMOUNT_DECLINED
AMOUNT_TOO_SMALL
400
UNAUTHORIZED

400
BATCH_CLOSING
BATCH_CLOSING 
400
RECAPTCHA_VERIFICATION_FAILED

429
TOO_MANY_REQUESTS

500
INTERNAL_ERROR

504
INTERNAL_ERROR
ISSUER_TIMEOUT

Errors Returned by 3DS

Error TypeError Code
Description
CARD_ERRORNOT_VERIFIED
Could not verify card number
CARD_ERRORNOT_AUTHENTICATED
Issuer rejected card
DOWNSTREAM_ERRORNOT_VERIFIED 
3DS provider is having technical issues

Verifying the HMAC

The HMAC is calulated using the following:

// JavaScript example
function generateHmacDigest(algorithm, key, message) {
const hmac = crypto.createHmac(algorithm, key);
hmac.update(JSON.stringify(message));
return hmac.digest('hex');
}

generateHmacDigest("sha256", "my-secret-key", transaction.response);

Where "my-secret-key" is the API secret for the merchant account. To verify the HMAC simply repeat the above calulation and compare the returned HMAC witht he generated HMAC.

Adding Option Fields


By default, SCH displays the minimum number of fields needed to validate a credit card online. These are the cardholder namecard numberexpiry date, and CVV fields. SCH can also display fields for address, postal code, email address, as well as change the display behavior of the Pay button. By default, the Pay button's behavior changes from the word Pay to a spinner; you can choose to disable this functionality.

To include these fields, you need to supply the optional values when creating the secure token.

javascript
javascript
const body = {
avs: 'both',
amount: 'editable',
disableSubmitIndicator: true,
email: true,
expires: '2025-06-24T13:50:00.0Z',
ignoreInitAuthTimedOut: true,
invoice: 'disabled',
invoiceNumber: 'abc-123',
language: language,
purchaseAmount: 100,
transactionType: 'PURCHASE',
useRecaptcha: false
}

 SHC supports a number of fields that can be used to display different fields or turn different features on or off.
Below is a list of fields that SHC currently supports:
  • avs: display the address and postal fields.

    • Valid values are 'address', 'postal', or 'both'.

    • If full AVS is enabled in the merchant account, ignore these values. For partial or optional AVS, pass the correct value to show the appropriate fields.

  • amount: display the amount field. Valid values are ‘disabled', ‘editable’, and 'hidden’.

    • If the transaction type is 'PURCHASE' or 'PREAUTHORIZATION' and purchaseAmount is not passed then the amount field will be displayed.

    • If purchaseAmount is not empty and amount is not passed then the amount field will be hidden.

  • disableSubmitIndicator: hide the submit indicator

    • When set to true the submit indicator on the Pay button will not be displayed

  • email: display the e-mail address field

    • When set to true the the e-mail field will be displayed.

    • If 3DS is active then this value is ignored

  • expires: set the expiry date and time for the secure token

    • The date and time the token will expire in ISO-8601 format.

    • The default is five minutes from creation time

  • ignoreInitAuthTimeout: ignore 3DS authentication timeout errors

    • Set to true to ignore 3DS authentication initialization errors

  • invoice: display the invoice number field.

    • Valid values are ‘disabled', ‘editable’, and 'hidden’.

  • invoiceNumber: an invoice number, maximum 25 characters long.

    • If a value is passed and the invoice field is not set, then invoiceNumber will be displayed as a read only field.

  • language: language to display fields in.

    • Valid values are 'en' and 'fr'.

    • This field is mandatory.

  • purchaseAmount: value of the transaction to be performed

    • if the transaction is a PURCHASE or PREAUTHORIZATION this field can contain the amount in lowest ordinal format (i.e. 1 dollar is passed in as 100)

    • NOTE: If the transaction type is 'PREAUTHORIZATION' or 'PURCHASE', then purchaseAmount is a mandatory value.

  • transactionType: type of transaction to perform

    • Valid values are 'PURCHASE', 'PREAUTHORIZATION', and 'VERIFY'.

    • This field is mandatory

  • useRecaptcha: disable reCAPTCHA

    • Is set to true by default

    • Set to false to turn off reCAPTCHA

A Note on purchaseAmount

When the purchaseAmount is part of the session request then that is the value used when the transaction is processed rather than the value passed down by the form. This means that setting purchaseAmount as an option will have no effect.

A Note on Verify Transactions

If a purchase or preauthorization is required after a verify, the response contains a token which can be used. See below for an example of how to perform a purchase or preauthorization.


Payment tokens generated by SHC can be used in subsequent calls to generate a purchase or a pre-authorization.

javascript
javascript
function postCharge(amount, invoiceNumber, token, isPurchase) {
const capture = isPurchase === true; // if capture is true then it is a purchase,
// else it is a pre-authorization
const endpoint = `https://uat.ca.api.payfacto.cloud/payments/v1/charges`;
const body = {
amount: amount,
cature: capture,
invoiceNumber: invoiceNumber,
paymentMethod: {
type: "PAYMENT_TOKEN",
paymentToken: { storedCredential: { type: "CIT_INITIAL", tokenId: token } }
}
};
const payload = {
method: 'POST',
headers: {
Authorization: 'Basic YOUR API KEY HERE',
Accept: 'application/json',
'Content-Type': 'application/json; charset=utf-8',
'idempotency-key': crypto.randomBytes(16).toString('base64')
},
body: JSON.stringify(body)
}

fetch(endpoint, payload)
.then(response => {console.log( response.status); return response.json() })
.then(data => console.log(JSON.stringify(data, null, 2)))
.catch(error => console.error(error));
}
 

Disabling useRecaptcha

SHC uses Google's reCAPTCHA to prevent some automated attacks. For security purposes, the useRecaptcha option is set to true by default.

However, some merchants have reported that using Google's reCAPTCHA interferes with their site. In these rare instances, SHC allows you to disable this security feature.

If you pass the useRecaptcha as false in the options, you are disabling the SHC reCAPTCHA feature and you risk exposing your custom form to various attacks, including a velocity attack.

Usage of ignoreInitAuthTimeout

As part of the 3D Secure authentication process, SHC collects information about the device and browser used by the customer. In rare cases, this process can cause a timeout and generate an initAuthTimeout error which can cause the transaction to fail. Setting ignoreInitAuthTimeout to true will ignore the the timeout error and allow the rest of the 3D Secure process to continue.

If you pass ignoreInitAuthTimeout as true, part of the 3D Secure process is bypassed and the merchant may be liable for fraudulent transactions.

Options, the Third Argument

Adding an additional argument to render fields correctly

In some cases, additional information can be added to change the behaviour of SHC when it is called. In those cases you can provide a third argument containing options. Below is a list of options that SHC currently supports:
  • cardholderName 

    • when the cardholder's name is passed in the name field is hidden and the value is preserved in the hidden field

  • fields

    • An object containing values to add to the form and how to display them

  • invoiceNumber 

    • when passed in the value is preserved in a hidden field.

    • If the invoice flag is set then the value is displayed in the field

  • purchaseAmount 

    • when passed in the amount field is hidden and the value is preserved in a hidden field. If the transaction type is 'PREAUTHORIZATION' or 'PURCHASE' then this value is ignored when processing the transaction in favour of the value passed on the session create call.

  • sourceElement 

    • override shc-fields as the default location to add the fields in

  • useOldStyleResponse 

    • use the older style response objects. Used for backwards compatibility with older versions of SHC


    The fields Option

    The third argument, options, in the shc function includes the fields object, which contains values to be passed to the server on submit. The keys will be the names of the fields and the values are the content to be loaded in the fields and their visibility.
    const options = {
    fields: {
    invoiceNumber: { visibility: "", "value": "" },
    purchaseAmount: { visibility: "", "value": "" },
    cardholderName: { visibility: "", "value": "" },
    email: { visibility: "", "value": "" },
    address: { visibility: "", "value": "" },
    postal: { visibility: "", "value": "" }
    }
    }

    Only the fields to be pre-loaded are required. The visibility and value properties are mandatory. If one of the properties is missing an exception will be thrown. The visibility property can contain one of the following three values: hidden, disabled, or enabled. The contents of the value field are not tested for correctness.

    There are already options in place for passing purchaseAmount, invoiceNumber, and cardholderName. The old methods will work by default but will be overridden by the options in fields if they exist.

    sourceElement

    When working with custom forms, SHC requires the id of the tag containing the form. This id is passed to SHC as the sourceElement property in the options parameter.

    The following example shows how to use the sourceElement property as a third argument:

    javascript
    javascript
    const options = { sourceElement: ‘custom-form’ };
    shc(shcToken, response => handleResponse(response), options);
     

    Customizing

    Customizing the Look of the SHC Fields

    Custom Forms

    To create a custom form, the merchant creates the form inside a div tag and then passes the id of that div tag to the shc function using the sourceElement property in the options object (i.e.: shc(secureToken, callback, { sourceElement: merchantForm }).)

    The function will then use this form instead of generating its own. As part of the setup, all of the listeners will be stripped from the copied fields. To make use of the shc listeners add the id of the listener you want to emulate to the field.

    For example, to take advantage of shc's card formatting, add id="shc-card-input" to the custom card field. If a field is marked with the required attribute the Pay button will not be enabled until the field contains a value.

    When the form is submitted the contents of all the user defined fields will be part of the response in the callback.

    Custom Messaging

    In a custom form, buttons that contain the attribute data-message will send the contents of that message in a message to the parent form via a message. You can use a message event listener (i.e.: window.addEventListener('message', messageEventHandler);) to listen for the event. The message will use the format { message: 'data-message contents' }.


    Styling

    Styling the form to match your website

    SHC provides a number of CSS classes that you can override to change the appearance of the SHC fields. The classes are structured so you can overwrite fields as a group, allowing for consistency across all the fields. If inconsistency is desired or required, each element has its own unique id which allows for granular manipulation of each element in the form.

    A field's generic layout resembles the following:

    javascript
    javascript
    <label for="${name}" id="shc-${name}-label" class="confidante-field-label">
    <div id="shc-${name}-img" class="confidante-field-img"></div>
    <input id="shc-${name}-input" required="required" type="text" class="confidante-field-input shc-field-${name}" name="${name}" placeholder="${placeholder}" />
    <span id="shc-${name}-span">${label}</span>
    <div id="shc-${name}-validate" class="confidante-field-validate"></div>
    </label>
     Where ${name} represents the field name. Valid field name values are:
    • name 
      • : The cardholder's name on the card.
    • card: The card number.
    • expiry : The card's expiry date.
    • cvv: The three or four digit CVV number on the back of the card.
    • email : The cardholder’s email address.
    • address : The cardholder’s postal address.
    • postal : The cardholder’s postal code.
    • amount: The purchase amount
    • invoice: the invoice number

    Where to Put the CSS Styles

    To apply the CSS styles, you need to put the shc-style id in a style tag, as shown in the following example:
    javascript
    <style id="shc-style">
    /* place the custom styles here */
    </style>
    This ensures that all the styles in this tag will be applied to the SHC fields and buttons.


    Example

    Hiding Images

    If you want to hide all the images at the start of the field, use the following CSS code:

    CSS
    CSS
    .confidante-field-img svg {
    visibility: collapse;
    }

     

    To hide the image, use the following CSS code:

    CSS
    CSS
    #shc-card-img {
    visibility: collapse;
    }
     To hide the images and move the field labels over, use the following CSS code:
    CSS
    CSS
    .confidante-field-img svg {
    visibility: collapse;
    }

    .confidante-field-validate svg {
    visibility: collapse;
    }

    /* this style moves the label to the area the image icon used to cover */
    label > span.confidante-field-span {
    transform: translate(16px,34px);
    }

    /* this style starts the input text in the area the image icon used to cover */
    input {
    padding: 10px 0px 10px 16px;
    }
     Hide and Move Images

    To move the images to the right side of the input fields, use the following CSS code:

    CSS
    CSS
    .confidante-field-img svg {
    left: auto;
    right: 5px;
    }
    .confidante-field-validate svg {
    display: none;
    }
     Move images to Right

    Freeze Labels Above the Field

    CSS
    CSS
    /* increase the border to encompass the label */
    input {
    padding: 24px 16px 16px 40px;
    }

    /* freeze the icons in their locations */
    .confidante-field-img svg {
    margin-top: 14px;
    }

    .confidante-field-validate svg {
    margin-top: 14px;
    }

    /* move the labels to a new location */
    label > span.confidante-field-span {
    position:absolute;
    top: 0px;
    left: 10px;
    font-size:0.825em;
    transform: translate(-4px, 6px);
    }

    /* prevent the labels from moving */
    label:focus-within > span.confidante-field-span,
    input:not(:placeholder-shown) + span.confidante-field-span {
    transform: translate(-4px, 6px);
    font-style: initial;
    }

    /* keep the card number mask in place over the card number */
    .confidante-field-mask {
    top: 25px;
    }
     Freeze Labels

    Change the Entire Look of the Input Fields

    CSS
    CSS
    /* restyle the label */
    #shc label {
    margin-bottom:15px;
    position:relative;
    border: 0px;
    border-bottom: 1px solid #ddd;
    box-shadow: none;
    }

    /* move the input field to align with the label */
    #shc input:not(.shc-hidden-fields) {
    width:100%;
    padding: 20px 0px 10px 0px;
    margin-top:20px;
    border:none;
    outline:none;
    }

    /* adjust the position of the label */
    #shc span.confidante-field-span {
    position:absolute;
    top:0;
    left:0;
    transform:translateY(40px);
    font-size:0.825em;
    transition-duration:400ms;
    }

    /* restyle the button */
    #shc button {
    padding:15px 0px;
    margin-top:20px;
    background:purple;
    color:#fff;
    border:1px solid purple;
    cursor:pointer;
    border-radius:3px;
    }

    /* change the colour and position of the label when the input is focused or has text */
    #shc label:focus-within > span.confidante-field-span,
    #shc input:not(:placeholder-shown) + span.confidante-field-span {
    color:purple;
    transform:translate(32px, 12px);
    }

    /* make sure the mask is over the input field */
    .confidante-field-mask {
    top: 40px;
    left: 5px;
    }

    /* change the colour of the svg icon when the input is focused or valid */
    label:focus-within > .confidante-field-img svg,
    .confidante-field-label.valid > .confidante-field-img svg {
    fill: purple;
    }
     New Look

    Customizing the Pay Button

    You can also customize the Pay button. The default layout for the button field is shown below:
    javascript
    javascript
    <button id="shc-pay-button" type="button" class="disabled">Pay</button>
     By using the #shc-pay-button CSS identifier, you can add different styles to the Pay button.

    Removing the Border

    To remove the border around SHC, use the following CSS:

    CSS
    CSS
    #target {
    border:0;
    padding: 0px;
    padding-top: 20px;
    }
     
    Hide Border

    Creating a Custom Form

    No need to use the default, custom forms allow for a standardized look that matches your website

    Creating your Own Custom Form

    SHC allows a merchant developer to create a custom form allow for a standardized look that matches their website.
    The form can contain both SHC fields and the merchant’s own fields. To designate a field as an SHC field, the field id must be the same as the id of an auto-generated SHC field. Valid field ids are:
    • shc-name-input: 
      • The cardholder name field.
    • shc-card-input 
      • The card number field.
    • shc-expiry-input 
      • The card expiry date field.
    • shc-cvv-input 
      • The card's CVV value field.
    • shc-email-input 
      • The cardholder's email address field.
    • shc-address-input 
      • The cardholder's postal address field.
    • shc-postal-input 
      • The cardholder's postal code field.
    • shc-amount-input
      • The purchase amount field
    • shc-invoice-input
      • The invoice field

    If a field has an SHC field id, all the formatting and listeners will be applied to that field.
    When the Pay button is clicked, the values in the user fields will be collected and returned to the caller.

    javascript
    javascript
    <div id="custom-form">
    <form style="display: flex;">
    <input id="secureId" name="secureId" type="hidden" value="bonJeton" />
    <input type="hidden" name="name" value="JOHN DOE" />
    <input type="text" id="shc-card-input" name="card" placeholder="1234 1234 1234 1234" required="required" autocomplete="cc-number" />
    <div style="display: flex; flex-direction: row;">
    <input type="text" id="shc-expiry-input" name="expiry" placeholder="MM / YY" required="required" />
    <input type="text" id="shc-cvv-input" name="cvv" placeholder="123" required="required" autocomplete="cc-csc" />
    </div>
    <button id="shc-pay-button" type="button">Pay</button>
    </form>
    </div>
     

    In order to use your custom form you will need to pass the form's id to shc as an option in the third argument.

    Custom Required Fields


    If you need to add a required custom field, you must set the required attribute on the field in order to prevent the Pay button from being enabled until that custom field contains a value.

    Custom Forms and 3DS

    When working with custom forms the merchant is responsible for adding the hidden 3DS fields.

    javascript
    javascript
    <input id="purchaseAmount" name="purchaseAmount" type="hidden" value="920">
    <input id="purchaseCurrency" name="purchaseCurrency" type="hidden" value="CAD">
    <input id="purchaseDate" name="purchaseDate" type="hidden" value="2025-11-03T18:16:43.948Z">
     All three fields must be present and all three fields must have the following names and values:
    • purchaseAmount: the monetary amount of the transaction denoted in minor units.
      • So in the above example the value is $9.20, not $920.00.
    • purchaseCurrency: the currency that the transaction will be conducted in.
      • For most merchant accounts the value will be “CAD” for Canadian dollars.
      • Note that the currency must be the same as the merchant account’s currency.
    • purchaseDate: the date and time the transaction is taking place in extended ISO-8601 format (YYYY-MM-DDTHH:MM:SS.000Z)

    The fields will be treated as read only by SHC so the required values can be safely pre-loaded before SHC is called.

    Custom Form Security Features


    To protect against the possible injection of fraudulent code, SHC prevents the transfer of the following HTML tags to the SHC secure iframe:

    • <SCRIPT>
    • <IFRAME>
    • <OBJECT>
    • <A> (the anchor tag)
    • <INPUT TYPE=”SUBMIT”>
    • <BUTTON TYPE=”SUBMIT”>

    As an added measure of security. the ACTION and METHOD attributes are removed from the <FORM> tag.

    In addition to disallowing certain tags and attributes, no JavaScript is transferred to the SHC secure iframe. This includes JavaScript that is part of a permissible HTML tag or any events that were attached to an HTML tag before transferring the form to the SHC secure iframe.

    Custom Events

    In a custom form, buttons that contain the data-message attribute will send the contents of that message in a message to the parent form via a message.

    You can use a message event listener (i.e.: window.addEventListener('message', messageEventHandler);) to listen for the event. The message will use the { message: 'data-message contents' } format.


    The shcMessenger Object

    Enables the SHC form to communicate with the application calling the form

    shcMessenger

    The shcMessenger object allows the shc form to communicate with the calling application. The shcMessenger is created when the shc function is called.
    javascript
    javascript
    let shcMessenger;
    getShcToken(shcToken => {
    shcMessenger = shc(shcToken, response => processResponse(response), options);
    });


    Receiving Messages

    The shc form emits messages during execution. The calling application can receive those messages and act on them using the shcMessenger.on method. This method takes two arguments:
    • The message being listened for
    • The callback to handle the message

    The resulting call resembles the following:

    javascript
    javascript
    shcMessenger.on('shc-event', optionalData => handleEvent(optionalData));
     
    The list of message events that the calling application can receive is:
    • shc-card-brand 
      • The detected card brand when the cardholder enters the number. This message forwards an object containing the brand { brand : cardBrand }.
    • shc-submit 
      • The card information has been submitted for verification.
    • shc-response 
      • The same response being sent to the shc callback. Please refer to the callback documentation for details on what is sent in the data object.
    • shc-3ds 
      • The three-d-secure process has started.
    • shc-3ds-challenge 
      • The three-d-secure challenge flow is being executed.
    • shc-ready-to-submit 
      • All of the validation passes and the form can be submitted. This message forwards an object containing the ready status { isReady: true }.
      • NOTE: If the user changes a value in the required fields and validation no longer passes, the message object will contain the status { isReady: false }.

    Sending Messages

    The shc form can accept messages from the shcMessenger. These messages are sent via method calls on the object. The messages currently available to send are:
    • sendBlockSubmit() 
      • The method requests that the shc form not consider itself as ready to submit until a sendUnblockSubmit() message is sent. 
      • NOTE: The Pay button will remain in a disabled state even when all the fields are valid.
    • sendUnblockSubmit() 
      • Cancel a sendBlockSubmit() and allow the shc form to be ready to submit after all of the fields are valid.
    • sendCancel() 
      • This method requests that the shc form destroy itself.
    • sendSubmit() 
      • Requests that the shc form submit itself. 
      • NOTE: The form is not submitted if any of the fields in the form are not valid.


    Working with 3D Secure

    3DS2 adds security to your online transactions

    If your merchant account is configured for 3DS2, PayFacto will automatically trigger the 3DS2 validation on every SHC transaction. 

    You can choose to preset the amount to be validated, or allow the customer to input the amount.
    If the purchase amount is not passed in then the amount input field will be automatically displayed.

    Calling SHC with the purchase amount would be similar to the following example:
    javascript
    javascript
    const options = {
    purchaseAmount: amountAsInteger,
    };

    merchantGetShcToken(shcToken => {
    shc(shcToken, response => merchantProcessResponse(response), options);
    });
    If a purchase amount is not passed in then the amount field will automatically be displayed.

    Testing 3D Secure


    To test your 3D Secure implementation there are several card numbers that will trigger different 3D Secure responses. Below are the different test scenarios and the card numbers that will trigger them in PayFacto's test environment:

    Frictionless Authentication without 3DS2
    This scenario will return success without engaging 3D Secure.

    Cardholder Name: Test Card
    Card numbers:

    • Visa: 4100000000000100
    • Mastercard: 5100000000000107
    • Amex: 340000000000108

    Expiry Date: 08/27
    CVV: 123 or 1234

    Frictionless Authentication with 3DS2
    This scenario will perform a 3D Secure validation and return success without a challenge.
    Cardholder Name: Test Card
    Card numbers:
    • Visa: 4100000000600008
    • Mastercard: 5100000000600005
    • Amex: 340000000600006
    Expiry Date: 08/27
    CVV: 123 or 1234
    Challenge Authentication with 3DS2
    This scenario will display a challenge page that will require the password “123456” to be successful.
    Cardholder Name: Test Card
    Card numbers:
    • Visa: 4100000000005000
    • Mastercard: 5100000000005007
    • Amex: 340000000005008
    Expiry Date: 08/27
    CVV: 123 or 1234

    Failed Authentication with 3DS2
    This scenario will display a challenge page that will fail when the password “111111” to simulate a failure.
    Cardholder Name: Test Card
    Card numbers:

    • Visa: 4100000000300005
    • Mastercard: 5100000000300002
    • Amex: 340000000300003

    Expiry Date: 08/27
    CVV: 123 or 1234

    Authentication Unavailable
    This scenario will provide an authentication unavailable.
    Cardholder Name: Test Card
    Card numbers:

    • Visa: 4100000000400003
    • Mastercard: 5100000000400000
    • Amex: 340000000400001

    Expiry Date: 08/27
    CVV: 123 or 1234

    Authentication Rejected
    This scenario results in the authentication being rejected.
    Cardholder Name: Test Card
    Card numbers:

    • Visa: 4100000000500000
    • Mastercard: 5100000000500007
    • Amex: 340000000500008

    Expiry Date: 08/27
    CVV: 123 or 1234

    E-Mail Receipts

    If the e-mail field is present in the SHC Token request, SHC will forward an e-receipt to the e-mail address in the field.


    Migrating from Legacy SHC


    New Endpoints

    There are two endpoints that the merchant needs to update to, one for the library, and one for the session. The new endpoints are listed below:
    Test environment:
    1. SHC library: https://uat.ca.shc.payfacto.cloud/secure-hosted-checkout/v1/browser/shc.js
    2. SHC session: https://uat.ca.shc.payfacto.cloud/secure-hosted-checkout/v1/sessions
    Production environment:
    1. SHC library: https://ca.shc.payfacto.cloud/secure-hosted-checkout/v1/browser/shc.js
    2. SHC session: https://ca.shc.payfacto.cloud/secure-hosted-checkout/v1/sessions

    New API Key

    When a new account is created a new API key will be provided by PayFacto.
    This new API key will replace the old one in the Authorization header when requesting a session token.

    New Authorization Header


    The legacy SHC solution used a combination of an api key in the Authorization header, plus a companyNumber and merchantNumber in the body. This new version of SHC requires the merchant api key username and password, base 64 encoded, in the Authorization header only.

    New Session Payload


    The new payload is much simpler than the old payload.

    In the new payload the following parameters are mandatory:

    • transactionType: the type of transactions SHC is to process
    • language: the language the form is to be displayed in
    javascript
    javascript
    {
    transactionType: "VERIFY",
    language: "fr"
    }
     All of the optional parameters have been maintained and some new ones have been added. 

    New Transaction Flows


    With the addition of the new transactionType parameter, SHC can now process purchases and preauthorizations directly instead of having to do additional calls to the API.

    This allows the collection of card information and the required transaction to be handled as a single step with the results of the transaction being returned to the caller.

    The three valid transaction types are now:

    • “PREAUTHORIZATION”
    • “PURCHASE”
    • “VERIFY”.

    New Transaction Types


    SHC now supports performing pre-authorization and purchases as well as verifications. This eliminates the extra calls to the API.

    1. To perform a purchase set transactionType to PURCHASE.
    2. To perform a pre-authorization set transactionType to PREAUTHORIZATION.
    3. To perform a verification set transactionType to VERIFY.

    If the request type is a CHARGE or a PREAUTHORIZATION the authCode will be returned as part of the response.


    Responses


    The successful response virtually the same as the response of Legacy SHC, with the exception being that a purchase or preauthorization will also return an authorization code (authCode.)

    The HTTP response codes for error conditions remain the same, but an expanded set of error messages are now available.


      • Related Articles

      • API v1.0 - SHC - Secure Hosted Checkout

        About SHC What is Secure Hosted Checkout? Secure Hosted Checkout (SHC) is a JavaScript library that allows merchants to collect and send cardholder information to PayFacto for verification without needing to access that information directly. When ...
      • Construct a Secure Hosted Checkout (Legacy) Log

        This article explains how to construct and put together all the sequential activities related to a Secure Hosted Checkout transaction for debugging purposes. 1. View log You can use this view log to help locating all these info easily and by ...
      • SHP - Secure Hosted Pages

        Secure Hosted Pages Migrating from Legacy Hosted Pages In an effort to simplify redirect, The new Secure Hosted Pages (SHP) is very different from the old version. The new SHP mirrors Secure Hosted Checkout (SHC) fairly closely, making it easier to ...
      • SPL - Secure Pay By Link

        Secure Pay By Link Secure Pay By Link (SPL) is a new offering from PayFacto that allows a merchant to defer a SHC session to another time. It does that by creating a link that the cardholder can follow to a hosted page. When the cardholder navigates ...
      • Hosted Payment Page

        Introduction This page aims to train future users of the secure redirection of the PayFacto payment solution. You will find in this page a description of the secure redirection service, the operation, the various call and return parameters, the ...