Contents

Action types

 

We will automatically perform an Action when criteria of a condition have been met. This page explains the different types of actions that can be configured on your Trust Payments account.

 


 

URL notifications

URL notification actions are requests sent from Trust Payments to a pre-defined URL.
These notifications contain information about requests processed on your Trust Payments account.

Click here to learn more


 

Info
We do not support localhost, loopback or multicast IP ranges in the URL.

 

There are three different notification flows you can choose from:

 

Online

  • The notification will be processed during the transaction.
  • Your customer will be made to wait for your server to respond.
  • In the event of failure, the notification will not be retried.

 

Offline

  • The notification will be scheduled during the transaction.
  • Scheduled notifications will be processed as soon as possible after the customer has been shown a response.
  • In the event of failure, the notification will be retried for approximately 48 hours.

 

Failover

  • The notification will be processed during the transaction.
  • Your customer will be made to wait for your server to respond.
  • In the event of failure, the notification will be scheduled to be sent again and will be retried for approximately 48 hours.

 

Notification
If multiple online notification actions meet the required conditions to be triggered, only the first online notification will be processed during the request and any other online notifications will be discarded. If there are no online notifications triggered but there are multiple failover notifications, only the first failover notification will be processed during the request and any other notifications will be scheduled to be sent at a later time (treated as offline notification).

 

Format of URL notification

The notification sent from Trust Payments will include a valid HTTP/1.1 Content-type header to be accepted by your system. For example:

 


Content-type: application/x-www-form-urlencoded; charset=UTF-8

 

The included field names and data will be urlencoded.

For example, if the notification contains the fields “baseamount”, “errorcode” and “orderreference” with values “2499”, “0” and “customerorder1” respectively, then the notification may look like the following (notificationreference field is always returned):

 


baseamount=2499&errorcode=0&notificationreference=1-A60356&orderreference=customerorder1

 

Authentication (notification security)

To ensure the notification has not been modified by a malicious user, a field called responsesitesecurity can be included in the POST to your system, when configuring the notification in MyST. This field contains a cryptographic hash of a predefined set of field values.

Using the example above, with the addition of a notification password of “password”, using the sha256 security algorithm, the notification may look like the following:

 


baseamount=2499&errorcode=0&notificationreference=1-A60356&orderreference=customerorder1&responsesitesecurity=033e6bcc1971f150c5a6d5487548b375b8971c9bdc1962b2cc1844d26ff82c2a

 

Padlock
If you update your action to use a new notification password, all future notifications sent from the queue (offline or failover) will include a notification hash generated using the new password.

 

Step 1: To check the notification is legitimate, concatenate the values of all the fields in the request (excluding notificationreference and responsesitesecurity), in order of field name, in ASCII alphabetical order.

 


24990customerorder1

 

Step 2: To the end of this, append your notification password. This leaves:

 


24990customerorder1password

Where “password” would be replaced with your own notification password.

 

Notification
If a field returned in a notification has multiple values (e.g. fieldname=bravo&fieldname=alpha), these are concatenated in the order they were submitted in request. When included in the example above, the string generated would be:

 


24990bravoalphacustomerorder1password

 

 

Step 3: Then generate a hexadecimal hash of this value using sha256 and ensure the value matches the value in responsesitesecurity:

 


033e6bcc1971f150c5a6d5487548b375b8971c9bdc1962b2cc1844d26ff82c2a

 

If the generated hexadecimal hash does not match the responsesitesecurity received from Trust Payments, the notification should not be accepted. In such a case, please contact our Support Team.

 

Using Secure Socket Layer / Transport Layer Security (SSL/TLS)

You can set up your system to receive URL notifications using SSL/TLS. In order to do so, your server must present a valid TLS certificate chain to the Trust Payments notifications client. A valid certificate contains the domain of the Notification URL in the common name of the certificate and the chain must correctly validate to an accepted certificate authority.

 

You must configure your system to accept incoming URL notifications on port 443.

Padlock
If the certificate is not signed by a known certificate authority (for example Verisign), your test notifications may work but you will need to use a valid CA for live transactions.

 

Response to Trust Payments

You must configure your system to respond to a notification with an HTTP 200 OK response. For example: “HTTP/1.0 200 OK”.

Your system must reply within 8 seconds of receiving a notification.

 

Retrying notifications

A notification is sent shortly after the criteria defined in the filters have been fulfilled. One notification is sent per request.

Notification
Each notification contains a unique reference that is called notificationreference. If we fail to receive a response to an offline or failover notification, the notification will be resent with the same notification reference for up to 48 hours.

 

Email alerts for failed URL notifications

Once a day, we will send email alerts for failed URL notifications on your account. A URL notification failure may be attributed to an invalid URL or if we fail to receive a response from your system.

The alert is sent to the email address of the user that configured the notification and has a subject of “Notification Problems”. For example:

 

 

Envelope
Ensure your email server is configured to accept all incoming emails from [email protected].

 

Fields to include

When creating the action, use the “Fields” tab to specify fields to be included in the notification.

 

 

Start to type the name of the fields you would like to include to filter down the list displayed, and tick the fields to add them to the action.

 

 

We recommend including at least the following fields as a minimum for inclusion in typical URL notifications:

  • Acquirer Response Code (acquirerresponsecode)
  • Acquirer Response Message (acquirerresponsemessage)
  • Auth Code (authcode)
  • Base Amount (baseamount) (e.g. £10.50 is “1050”)
  • Currency (currencyiso3a)
  • Error Code (errorcode)
  • Live Status (livestatus)
  • Order Reference (orderreference)
  • Parent Transaction Reference (parenttransactionreference)
  • Payment Type (paymenttypedescription)
  • Request Type (requesttypedescription)
  • Settle Status (settlestatus)
  • Site Reference (sitereference)
  • Transaction Reference (transactionreference)


 

 

Payment pages customer email

This action is used to send an email to the customer’s billing email address following a Payment Pages transaction, when the associated condition(s) has been met (e.g. for successful transactions).

Click here to learn more


 

Customer email notifications are sent from Trust Payments’s systems when pre-specified criteria are met. These are designed to be sent to your customers, and can act as a receipt or confirmation following a transaction.

When enabled, please inform your customer to expect an email notification when they make a purchase.

Within the action, you can specify the “from” and “reply to” addresses and also the subject.

 

Screenshot of customer email

 

Included fields

The following fields are included as default within email notifications:

  • Amount
  • Auth Code
  • Billing County
  • Billing Email Address
  • Billing Full Name
  • Billing Postcode
  • Billing Premise
  • Billing Town
  • Currency
  • Merchant Name
  • Order Reference
  • Request Type
  • Transaction Reference


 

 

Payment pages merchant email

This action is used to send an email to yourself and/or members of your organisation following a Payment Pages transaction, when the associated condition(s) has been met.

e.g. For successful transactions over £600, send an email confirmation to [email protected]

Click here to learn more


 

Merchant email notifications are sent from Trust Payments’s systems when pre-specified criteria are met. These are designed to be sent to your company, containing a customised selection of fields.

Please ensure your email server is configured to accept all incoming emails from the email address you specified when configuring the notification.

Within the action, you can specify the recipient, email subject and “from” and “reply to” addresses.

 

Screenshot of merchant email

 

Included fields

The following fields are included as default within email notifications:

  • Amount
  • Auth Code
  • Billing County
  • Billing Email Address
  • Billing Full Name
  • Billing Postcode
  • Billing Premise
  • Billing Town
  • Currency
  • Merchant Name
  • Order Reference
  • Request Type
  • Transaction Reference


 

 

Payment pages redirect

This action is used to redirect the customer’s browser from the Payment Pages following a transaction, when the associated condition(s) has been met. The customer’s browser bypasses Trust Payments’s default response page and is redirected to the URL specified in the action.

e.g. For successful transactions, redirect the customer’s browser to your website.

Click here to learn more


 

Please note: We do not support localhost, loopback or multicast IP ranges in the URL.

Info
Redirect actions are always performed after all other action types. If multiple redirect rules are present, the first rule which meets the criteria will be used (e.g. UDR-1000 is run before UDR-1001).

 

Fields to include

When creating the action, use the “Fields” tab to specify fields to be included in the redirect.

 

 

Start to type the name of the fields you would like to include to filter down the list displayed, and tick the fields to add them to the action.

 

 

You should include the errorcode, settlestatus and transactionreference fields as a minimum, as these are used to indicate whether or not the transaction was successful.  You can also include custom fields, by typing the name and ticking it from the list.

 

Format of custom fields

  • Any lowercase or uppercase letters
  • Numbers 1-9
  • Punctuation: _ \ .
  • Must start with a letter (A-Z, a-z)


 

 

Payment pages required fields

This action is used to designate fields as required on the Payment Pages when the associated condition(s) has been met.

e.g. For Mastercard transactions, you could specify the billing name as required.

Click here to learn more


 

If the customer fails to enter the information required when performing a payment, the relevant fields are highlighted in red and the customer is shown an error message to convey the problem. This allows the customer to make corrections and re-attempt the payment.

All required fields are highlighted with an asterisk.

When creating the action, you will need to specify the fields required when the condition has been met.


 

 

Update response action

This action is used to automatically update the status of a request after it has been processed by the acquirer and the associated condition(s) has been met. e.g. For authorisations, where the results of the AVS checks return a “Not matched” postcode response, update the settle status in order to suspend the payment.

Info
By implementing the update response action, transactions may be left in a different status than before. Therefore, when enabling an update response rule, ensure any other active rules are updated to take this account.