FAQs

Unless you are using your own MPI to process the authentication, 3-D Secure is no longer supported when utilising our Webservices API.

Therefore, our Webservices API should only be utilised by merchants processing Mail or Telephone Order (MOTO) payments, Merchant Initiated Transactions (MIT), back-office requests to view or update details of existing transactions, or other workflows that are exempt from the PSD2 mandate.

To develop a payment solution that supports the latest 3-D Secure protocol (version 2), you will instead need to integrate using either our JavaScript Library (for web-based solutions) or our Mobile SDKs (for native mobile apps).

 

---

Yes. Click here to learn more.

You will need to process a REFUND request. REFUND requests can only be processed once the payment has been settled (status 100).

• Click here to learn more to learn about refunds.
• Click here to learn more about settlement.

 

---

You will need to process a new AUTH request through our Webservices API, ensuring you include the parenttransactionreference field. This is used to retrieve the payment credentials from the referenced transaction in order to process a new transaction.

 

---

We refer to authorisations, where no funds are reserved on the customer’s bank account, as “Account Checks”. You will need to process an ACCOUNTCHECK request through our Webservices API.

Click here to learn more.

 

---

An Account Check is a type of request that performs a zero-authorisation, during which checks on the customer’s address and security code are performed. No funds are reserved on the customer’s bank account as part of this process. When enabled, Account Checks are performed immediately prior to each standard authorisation on your account. This allows you to use the results returned to prevent authorisations from being processed, in cases where the aforementioned checks have shown there to be inconsistencies between the values entered by the customer and those being held on record by the issuing bank.

Click here to learn more.

 

---

• Payments processed as “pre-authorisations” can be deferred up to 31 days.
• Payments processed as “final authorisations” (default behaviour) can be deferred up to 4 days.

Click here to learn more about pre and final authorisations.

 

There are two ways in which a payment can be deferred until a later time.

1. You can include a settleduedate in your request. Funds will be reserved on the customer’s account, but won’t leave their account until the date specified.
2. You can suspend a transaction, by submitting settlestatus=2 in your request. Funds will be reserved on the customer’s account, but won’t leave their account until the transaction is updated to settlestatus=1.

Click here to learn more about the settlement and deferral.

When developing a native iOS app that supports Apple Pay, we recommend using our iOS SDK. And if you are developing a web-based solution, we recommend our JavaScript Library integration.

Alternatively, if you have / plan on having a direct integration with Apple to process Apple Pay on the web and simply need a method of submitting the payment card wallettoken for authorisation to Trust Payments, you can follow this document to learn how.

 

---

You will need to sign in to your PayPal account and perform steps to allow it to connect to Trust Payments. Then you will need to use our Webservices API to process the transactions.

Click here to learn more.

 

---

For a full list of Alternative Payment Methods supported by our Webservices API, click here.

 

---

Providing you have a recurring merchant account, you can schedule subscriptions in our Subscription Engine. This means that following the customer’s first transaction, Trust Payments will automatically process repeat payments at regular intervals defined in the request. Subscriptions must be implemented by using our JavaScript Library or Mobile SDK, to allow the first payment to be authenticated with 3-D Secure (to ensure compliance with the PSD2 mandate).

Yes, providing your acquiring bank accepts the currencies needed and your Trust Payments account has been configured to do so. You can even configure and enable currency conversion, allowing your customer to pay in the local currency of their choosing.

Yes. Click here for a full list.

When you sign up, you will be provided with a “test” site reference and a “live” site reference:

Test site references are prefixed with “test_”: e.g. “test_site12345”
All requests from your test site reference are processed within our sandboxed test environment, meaning no funds change hands. We recommend thoroughly testing your solution using your test site reference prior to going live.
Click here for further information on how to perform tests.

Live site references are not prefixed with “test_”: e.g. “site12346”.
When processing live transactions, you must use your live site reference, otherwise you will not receive funds. You can only process transactions in the live environment after you have completed your testing and followed the steps described in our Going live documentation.
Click here for information on Going live.

 

---

We provide a list of card numbers on this page. These can be used to simulate different transaction outcomes.

 

---

You will need to follow the steps provided on this page to begin processing live payments.

You must ensure you are following the specification as outlined in our Webservices API documentation.

The name of the field that is causing the error is returned in the response in field errordata.

When troubleshooting field errors, we recommend following these tips:

• Ensure all required fields are submitted.
• If a field is indicated to be conditional, ensure the field is submitted when the stated condition is met.
• If a field has a maximum or minimum length, ensure these requirements are also met.
• Ensure the field type is correct. E.g. if an integer is required, do not submit a string.

 

---

The most likely cause of this would be incorrect credentials in your Webservices header, or the username submitted has not been assigned a Webservices role. You can check the role of the user by signing in to MyST and viewing the user’s details.

 

---

The combination of payment type and currency submitted in your request is not currently supported by your account with us. You will either need to correct the currency submitted to be one supported by your account, or contact our Support Team to discuss enabling payment methods for additional currencies.

 

---

Please follow these three steps:

1. Please check transactions are definitely being processed through your live sitereference. If the sitereference posted in your request is prefixed with “test_”, payments are being processed on the test environment and you will never receive funds.
2. Check your transactions are being “settled”. Once transactions are authorised by the issuing bank, funds are reserved on the customer’s account (normally for up to 24 hours) before finally being transferred to your bank account in a process called “Settlement“. Settled transactions are indicated as such on the Transaction search page in MyST (the settlestatus value should also be “100”). If your transactions are not settling as expected, you will need to investigate why this is.
3. If you have confirmed transactions are being processed through your live sitereference and have been settled, there may be an issue with your bank account. We recommend contacting your acquiring bank for assistance.

 

---

Once transactions are authorised by the issuing bank, funds are reserved on the customer’s account (normally for up to 24 hours) before finally being transferred to your bank account in a process called “Settlement”. Settled transactions are indicated as such on the Transaction search page in MyST (the settlestatus value should also be “100”).

Click here to learn more about the settlement process.

When processing payments and handling transaction data, you need to ensure your solution is fully compliant with the Payment Card Industry Data Security Standard (PCI DSS).

PCI DSS aims to protect customer data from unauthorised access and ultimately to reduce the risk of fraud when processing payments online. It establishes requirements and best practices that all merchants must follow when handling sensitive payment credentials. The standard is administered by the Payment Card Industry Security Standards Council, a group that currently consists of Visa, Mastercard, American Express, Discover and JCB.

Click here to learn more.