SHC - Secure Hosted Checkout

SHC - Secure Hosted Checkout

Secure Hosted Checkout

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 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://shc.titan.uat.payfacto.cloud/secure-hosted-checkout/v1/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://shc.titan.uat.ca.payfacto.cloud/secure-hosted-checkout/v1/session 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.


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/session 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/session endpoint, requires secret information that could be stolen if it was available to the client application. The call to /secure-hosted-checkout/v1/session 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/session 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://shc.titan.uat.ca.payfacto.cloud/secure-hosted-checkout/v1/session';
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 => res.send(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.

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 card validation. When the validation is successful the resulting object looks like the following example:
javascript
javascript
{
  brand: "Visa",
  card: "411111******1111",
  cvv2Cvc2Status: "M",
  expiry: "1223",
  name: "Test Card",
  profileId: "72e042dd-a518-4ec2-8df0-58125f815a68",
  secureId: "656dp9d7058gf3958hlb5e53o37hr0x8kwi",
  success: true,
  token: "5k46v51j238tpt5v7v4u4a18hc4f04m9926"
}
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
    1. boolean indicating success or failure of the transaction
  2. token
    1. card token automatically generated as part of the process
  3. secureId
    1. the session ID
  4. transactionId
    1. The unique identifier of the transaction that was created
  5. avs
    1. the AVS response code
  6. authCode
    1. the authorization code
  7. issuerMessage
    1. message from the issuer
  8. isoResponseCode
    1. ISO response code from issuer
  9. status
    1. PayFacto payment platform status message
  10. purchaseDate
    1. The date and time stamp when the transaction was processed
  11. name
    1. cardholder name
  12. lastFour
    1. last four digits of the card number
  13. expiry
    1. expiry date of the card
  14. cvv2Cvc2Status
    1. The CVV response.
    2. Valid values are ‘M' for PASS and 'N’ for FAIL
  15. invoiceNumber
    1. Passed invoice number. If no invoice number is passed then one is generated on the fly
  16. purchaseCurrency
    1. The currency used to conduct the transaction

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
Y
5-Digit ZIP and street address match
Z
5-Digit ZIP matches, street address does not

The Error Response

Sometimes, things 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
{
  code: "INVALID_NUMBER",
  message: "card number is incorrect",
  success: false,
  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
BAD_REQUEST

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
HTTP CodeError TypeError Code

CARD_ERRORNOT_VERIFIED (could not verify card number)

CARD_ERRORNOT_AUTHENTICATED (issuer rejected card)

DOWNSTREAM_ERRORNOT_VERIFIED (3DS provider is having technical issues)

Adding Option Fields

By default, SCH displays the minimum number of fields needed to validate a credit card online. These are the cardholder name, card number, expiry 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 = {
  language: language,
  avs: both'both',
  email: true,
  amount: 'editable',
  disableSubmitIndicator: true,
  expires: '2025-06-24T13:50:00.0Z',
  invoice: 'disabled',
  invoiceNumber: 'abc-123',
  purchaseAmount: 100,
  transactionType: 'PURCHASE',
  useRecaptcha: false,
  ignoreInitAuthTimedOut: true
}
 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:

  • language

    • language to display fields in.

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

    • This field is mandatory.

  • avs

    • display the address and postal fields.

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

    • If AVS is set on the merchant accounts these values are ignored

  • email

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

    • If 3DS is active then this value is ignored

  • 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

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

  • expires

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

    • The default is five minutes from creation time

  • 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.

  • purchaseAmount

    • 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)

  • transactionType

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

    • This field is mandatory

  • useRecaptcha

    • Set to false to turn off reCAPTCHA

  • ignoreInitAuthTimeout

    • Set to true to ignore 3DS authentication initialization errors


Disabling useRecaptcha

SHC uses Google's reCAPTCHA to prevent 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 3rd 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:

  • sourceElement 

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

  • cardholderName 

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

  • 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

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

Making the payment page your own

Customizing the Look of the SHC Fields

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

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 at the start of the card field only, use the following CSS code:

CSS
CSS
#shc-card-img {
  visibility: collapse;
}
 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.

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
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.

You can customize forms and messages to suit your site and your customers.

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' }.


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. 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

Custom Form Security

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

Customizing what you can do with custom forms

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);
});

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:

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/25
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/25
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/25
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/25
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/25
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/25
CVV: 123 or 1234



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://ca.api.payfacto.cloud/secure-hosted-checkout/v1/browser/shc.js
  2. SHC session: https://ca.api.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.


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.


    • 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 ...