This article is only accessible directly via the URL.
Pay by Bank (also known as Account to Account or A2A) is a bank transfer payment method. Trust Payments provides Pay by Bank with a processing partner authorised by the financial regulators in the UK and EEA (European Economic Area). When opting to pay with Pay by Bank on your checkout, customers will be redirected to a page hosted by our processing partner, which will prompt them to select their bank. The bank will determine the next steps undertaken by the customer to authorise the payment, but typically the customer will be asked to perform some form of SCA (Strong Customer Authentication), e.g. reviewing and approving the order using a banking app installed on their device. Once they agree to the payment, the customer will finally be redirected back to your website. Authorised funds will be transferred to your virtual settlement account.
| Supported customer countries | GB |
| Supported currencies | GBP |
| Refunds | Not supported. |
| Chargebacks | Payments are not subject to chargebacks. |
| Zero-authorisation | Not supported. |
| Recurring payments | Not supported. |
Requirements
- Before you get started, you will need to contact our Support Team and request that Pay by Bank is enabled on your account.
- As part of this process, we will work with you to set up a URL notification for settlement. This is needed to notify your system that the funds have been settled into your virtual settlement account, and you can safely dispatch goods and services to customers.
- For testing purposes, we will first configure your test site reference for Pay by Bank. The test site reference will be connected to the Pay by Bank sandbox environment powered by a trusted third party, allowing you to test your solution before going live. Once you are ready to go live, we can then enable Pay by Bank on your live site reference.
Process overview
-
Initiate the payment session
- Customer agrees to a payment using Pay by Bank on the merchant’s website.
- Merchant submits AUTH request to initiate the session, including the returnurl.
- Merchant receives AUTH response, including redirecturl.
-
Redirect to bank login page
- Merchant redirects the customer’s browser to the redirecturl. This is a page hosted by a Trust Payments processing partner, which prompts the customer to select their bank.
- Customer is then redirected to pages hosted by their selected bank, where they will be prompted to sign in, review the order details and authorise the transaction.
-
Finishing the session
- Once the customer has finished on the pages hosted by their bank, their browser is redirected to the returnurl, a page hosted by the merchant, via a GET request.
- The merchant must check the value of the settlestatus field (as explained below).
- The merchant displays the appropriate success or error message on the webpage.
A successful order does not guarantee that funds will be settled into the merchant's virtual settlement account. Do not provide goods / services to the customer until you have received notification of settlement.
-
Settlement notification
- Provided that settlement notifications have been enabled as required, the merchant receives a URL notification from Trust Payments with settlestatus=100. This indicates that funds have reached the merchant's virtual settlement account, pending transfer to their bank, and it is safe to provide the customer with goods or services.
- At this step, we recommend merchants send an email to the customer informing them of the update to the status of their order. e.g. If settlestatus=100, the customer can be informed that the product they ordered has been dispatched.
Verifying the transaction status
At any time after the AUTH request has been sent, your system can query the status of a Pay by Bank transaction by submitting a TRANSACTIONQUERY request via our Webservices API. The only fields you need to include in the filter are your sitereference and the transactionreference of the AUTH. For example:
{
"alias":"webservices@example.com",
"version":"1.00",
"request":[{
"requesttypedescriptions":["TRANSACTIONQUERY"],
"filter":{
"sitereference":[{"value":"test_site12345"}],
"transactionreference":[{"value":"55-9-12345"}]
}
}]
}
Learn more about Transaction Query requests
In the response, check the settlestatus field to determine the transaction status:
Settling
If settlestatus = 10,
the customer has been redirected to their bank to authorise the transaction.
Settled
If settlestatus = 100,
the funds are now in your virtual settlement account following authorisation.
Cancelled
If settlestatus = 3,
the customer declined to authorise the transaction (or an error occurred).
Initiate the payment session
When the customer chooses to pay with Pay by Bank, your system will need to perform an AUTH request and, if successful, redirect the customer’s browser to the URL returned in the response.
Later in this article, we provide recommendations on how to present Pay by Bank on your checkout and tips for improving customer engagement.
AUTH request
The example request below is for a Pay by Bank AUTH request:
#!/usr/bin/python
import securetrading
stconfig = securetrading.Config()
stconfig.username = "webservices@example.com"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
auth = {
"requesttypedescription": "AUTH",
"sitereference": "test_site12345",
"accounttypedescription": "ECOM",
"returnurl": "https://www.example.com/success",
"baseamount": "1050",
"currencyiso3a": "GBP",
"paymenttypedescription": "ATA"
}
strequest = securetrading.Request()
strequest.update(auth)
stresponse = st.process(strequest) #stresponse contains the transaction response
<?php
if (!($autoload = realpath(__DIR__ . '/../../../autoload.php')) && !($autoload = realpath(__DIR__ . '/../vendor/autoload.php'))) {
throw new Exception('Composer autoloader file could not be found.');
}
require_once($autoload);
$configData = array(
'username' => 'webservices@example.com',
'password' => 'Password1^'
);
$requestData = array(
'requesttypedescription' => 'AUTH',
'sitereference' => 'test_site12345',
'accounttypedescription' => 'ECOM',
'returnurl' => 'https://www.example.com/success',
'baseamount' => '1050',
'currencyiso3a' => 'GBP',
'paymenttypedescription' => 'ATA'
);
$api = \Securetrading\api($configData);
$response = $api->process($requestData);
var_dump($response->toArray());
?>
curl --user webservices@example.com:Password1^ <DOMAIN>/json/ -H "Content-type: application/json" -H "Accept: application/json" -X POST -d '{
"alias": "webservices@example.com",
"version": "1.00",
"request": [{
"requesttypedescription": "AUTH",
"sitereference": "test_site12345",
"accounttypedescription": "ECOM",
"returnurl": "https://www.example.com/success",
"baseamount": "1050",
"currencyiso3a": "GBP",
"paymenttypedescription": "ATA"
}]
}'
{
"alias":"webservices@example.com",
"version":"1.00",
"request":[{
"requesttypedescription":"AUTH",
"sitereference":"test_site12345",
"accounttypedescription":"ECOM",
"returnurl":"https://www.example.com/success",
"baseamount":"1050",
"currencyiso3a":"GBP",
"paymenttypedescription":"ATA"
}]
}
<requestblock version="3.67" >
<alias>webservices@example.com</alias>
<request type="AUTH">
<operation>
<sitereference>test_site12345</sitereference>
<accounttypedescription>ECOM</accounttypedescription>
</operation>
<merchant>
<returnurl>https://www.example.com/success</returnurl>
</merchant>
<billing>
<amount currencycode="GBP">1050</amount>
<payment type="ATA"/>
</billing>
</request>
</requestblock>
Replace <DOMAIN> with a supported domain. View full domain list.
Field specification
| Field | Format | Description | |
| Required | accounttypedescription XPath: /operation/accounttypedescription |
Alpha (20) | Only “ECOM” (e-commerce) is supported. |
| Required | baseamount XPath: /billing/amount |
Numeric (13) | The amount of the transaction in base units, with no commas or decimal points, so £10 is submitted as 1000. This value must be greater than zero. (Max length may vary depending on your acquiring bank – Contact your bank for further info) |
| Required | currencyiso3a XPath: /billing/amount/@currencycode |
Alpha (3) |
The currency that the transaction will be processed in (in ISO3A format). For a list of currency codes supported by Pay by Bank, refer to the list found at the top of this page. |
| Required | paymenttypedescription XPath: /billing/payment/@type |
Alpha (20) | This value must be submitted as “ATA”. |
| Required | requesttypedescription XPath: /@type |
Alpha (20) | The value in the request must be “AUTH”. |
| Required | returnurl XPath: /merchant/returnurl |
URL (2048) | The URL that the customer will be redirected to once they have finished on the pages hosted by their bank, regardless of the outcome. |
| Required | sitereference XPath: /operation/sitereference |
Alphanumeric & underscore (50) |
The site reference relates to your individual account which you received on setup. If you do not know your site reference, please contact our Support Team. |
| Optional | orderreference XPath: /merchant/orderreference |
Alphanumeric including symbols (25)
Recommended length 25 characters or less (exact length dependent on acquiring bank). Failure to adhere to this requirement may result in the text being truncated in the transaction. |
Your unique order reference that can be stored on the Trust Payments system. |
AUTH response
{
'requestreference': 'An3ug1kap',
'version': '1.00',
'responses': [{
'requesttypedescription': 'AUTH',
'baseamount': '1050',
'currencyiso3a': 'GBP',
'paymenttypedescription': 'ATA',
'errorcode': '0',
'errormessage': 'Ok',
'livestatus': '0',
'merchantcountryiso2a': 'GB',
'merchantname': 'Test Merchant',
'operatorname': 'webservices@example.com',
'accounttypedescription': 'ECOM',
'redirecturl': 'https://web-app.sandbox.token.io/app/request-token/rq:xxx:yyy',
'settleduedate': '2022-02-09',
'settlestatus': '10',
'transactionstartedtimestamp': '2022-02-09 15:43:49',
'transactionreference': '1-2-345'
}]
}
array(3) {
["requestreference"] => string(9) "A0345jmuw"
["version"] => string(4) "1.00"
["responses"] => array(1) {
[0] => array(16) {
["requesttypedescription"] => string(4) "AUTH"
["baseamount"] => string(4) "1050"
["currencyiso3a"] => string(3) "GBP"
["paymenttypedescription"] => string(3) "ATA"
["errorcode"] => string(1) "0"
["errormessage"] => string(2) "Ok"
["livestatus"] => string(1) "0"
["merchantcountryiso2a"] => string(2) "GB"
["merchantname"] => string(13) "Test Merchant"
["operatorname"] => string(23) "webservices@example.com"
["accounttypedescription"] => string(4) "ECOM"
["redirecturl"] => string(61) "https://web-app.sandbox.token.io/app/request-token/rq:xxx:yyy"
["settleduedate"] => string(10) "2022-02-09"
["settlestatus"] => string(2) "10"
["transactionstartedtimestamp"] => string(19) "2022-02-09 15:43:49"
["transactionreference"] => string(7) "1-2-345"
}
}
}
{
"requestreference":"W23-fjgvn3d9",
"version":"1.00",
"response":[{
"requesttypedescription":"AUTH",
"baseamount":"1050",
"currencyiso3a":"GBP",
"paymenttypedescription":"ATA",
"errorcode":"0",
"errormessage":"Ok",
"livestatus":"0",
"merchantcountryiso2a":"GB",
"merchantname":"Test Merchant",
"operatorname":"webservices@example.com",
"accounttypedescription":"ECOM",
"redirecturl":"https://web-app.sandbox.token.io/app/request-token/rq:xxx:yyy",
"settleduedate":"2022-02-09",
"settlestatus":"10",
"transactionstartedtimestamp":"2022-02-09 15:43:49",
"transactionreference":"1-2-345"
}]
}
<responseblock version="3.67">
<requestreference>Xjhr1mcce</requestreference>
<response type="AUTH">
<billing>
<amount currencycode="GBP">1050</amount>
<payment type="ATA"/>
</billing>
<error>
<code>0</code>
<message>Ok</message>
</error>
<live>0</live>
<merchant>
<merchantcountryiso2a>GB</merchantcountryiso2a>
<merchantname>Test Merchant</merchantname>
<operatorname>webservices@example.com</operatorname>
</merchant>
<operation>
<accounttypedescription>ECOM</accounttypedescription>
</operation>
<other>
<redirecturl>https://web-app.sandbox.token.io/app/request-token/rq:xxx:yyy</redirecturl>
</other>
<settlement>
<settleduedate>2022-02-09</settleduedate>
<settlestatus>10</settlestatus>
</settlement>
<timestamp>2022-02-09 15:43:49</timestamp>
<transactionreference>1-2-345</transactionreference>
</response>
<secrand>WK</secrand>
</responseblock>
Field specification
| Field | Format | Description | |
| Returned | accounttypedescription XPath: /operation/accounttypedescription |
Alpha (20) | The value returned is “ECOM”. |
| Returned | baseamount XPath: /billing/amount |
Numeric (13) | The amount of the transaction in base units, with no commas or decimal points, so £10 is returned as 1000. |
| Returned | currencyiso3a XPath: /billing/amount/@currencycode |
Alpha (3) |
The currency that the transaction was processed in (in ISO3A format). For a list of currency codes supported by Pay by Bank, refer to the list found at the top of this page. |
| Returned | errorcode XPath: /error/code |
Numeric (1-5) |
The error code should be used to determine if the request was successful or not.
|
| Returned | errormessage XPath: /error/message |
Alphanumeric (255) |
This is the corresponding message to the above code. |
| Returned | livestatus XPath: /live |
Numeric (1) |
|
| Returned | operatorname XPath: /merchant/operatorname |
Alphanumeric (255) | The value of this field contains the name of the user that processed the request. |
| Returned | paymenttypedescription XPath: /billing/payment/@type |
Alpha (20) | This value returned is “ATA”. |
| Returned | redirecturl XPath: /other/redirecturl |
URL (255) | Redirect the customer’s browser to this URL, which is hosted by a Trust Payments processing partner, to allow the customer to complete the payment. |
| Returned | requesttypedescription XPath: /@type |
Alpha (20) | The value returned is “AUTH”. |
| Returned | settleduedate XPath: /settlement/settleduedate |
Date YYYY-MM-DD | The date on which the transaction will be settled. |
| Returned | settlestatus XPath: /settlement/settlestatus |
Numeric (3) | This allows you to determine the status of the payment. Refer to the Handling the AUTH response section below for information on how to best interpret this field. |
| Returned | transactionreference XPath: /transactionreference |
Alphanumeric including hyphens (25) |
A unique reference for the transaction assigned by Trust Payments. |
| Returned | transactionstartedtimestamp XPath: /timestamp |
Date time YYYY-MM-DD hh:mm:ss | The time the transaction was processed. |
| Conditional | errordata XPath: /error/data |
Alphanumeric (255) |
Additional information to help troubleshoot the error. Only returned if there has been an error. |
| Conditional | merchantcountryiso2a XPath: /merchant/merchantcountryiso2a |
Alpha (2) |
These are details associated with the account used to process the transaction. To amend these fields, please contact our Support Team. Values returned depends on your account configuration.
|
| Conditional | merchantname XPath: /merchant/merchantname |
Alphanumeric (255) |
Handling the AUTH response
The settlestatus returned in the AUTH response is used to determine the status of the Pay by Bank payment:
If settlestatus=10,
the customer is ready for redirect
- Redirect the customer’s browser to the redirecturl so they can authorise the transaction.
- You will not receive funds until the customer completes this authorisation.
If settlestatus=3,
the payment was cancelled
- The payment has been declined or encountered an error.
- Inspect the errorcode to determine the reason. e.g. “70000” = Declined. Full list of error codes.
- We recommend displaying an error and presenting other payment methods so the customer can retry.
Redirect to bank login page
Your system will need to redirect the customer’s browser to the redirecturl, which is a page hosted by a Trust Payments processing partner, in order to process the payment.
As part of this, the customer will be further redirected to pages hosted by their bank, where they will be prompted to sign in to their account and authorise the transaction.
Do not display the redirecturl within an iframe. This will prevent the content from being rendered correctly, and can ultimately prevent the payment from being completed successfully.
When testing, the browser will display the sandbox environment. To complete a test transaction, the user needs to play the role of customer and follow the instructions displayed on screen. This will typically involve entering test credentials supplied by your account manager and/or selecting the desired transaction outcome from options presented on screen.
Do not enter your real card or banking information while testing!
Once the customer has authorised the transaction with their bank, their browser will be redirected to the returnurl included in the AUTH request.
Finishing the session
The customer returns from the pages hosted by their bank to the returnurl hosted on your site, in the form of a GET request containing the fields described below:
| Field | Format | Description | |
| Returned | orderreference |
Alphanumeric including symbols (25) |
Your unique order reference stored on the Trust Payments system. This field is returned blank if omitted from the AUTH request. |
| Returned | settlestatus |
Numeric (3) |
This allows you to determine the status of the transaction. Refer to the Handling the returnurl section below for information on how to best interpret this field. |
| Returned | transactionreference |
Alphanumeric including hyphens (25) |
Unique reference of the transaction, available after a payment request has been processed. You will need to use this in a subsequent TRANSACTIONQUERY request with our Webservices API to establish the current state of the payment, as described below. |
Handling the returnurl
The settlestatus returned in the returnurl is used to determine the current status of the Pay by Bank transaction:
If settlestatus=10, the customer authorised the transaction
- The transaction was authorised by the customer, but settlement is still pending.
- Pay by Bank settlement typically only takes a few minutes but can take longer (up to 2 days).
- We recommend displaying "Order successful" and emailing confirmation to the customer.
- Your server listens for a settlement URL notification before providing goods / services.
If settlestatus=100, transaction has already been settled
- The transaction has been settled. You can safely provide goods / services to the customer.
- We recommend displaying a success message and emailing confirmation to the customer.
- Your server still needs to listen and respond to the URL notification (as explained below).
If settlestatus=3, the payment has been cancelled
- The payment has been declined or encountered an error.
- We recommend displaying an error and presenting other payment methods so the customer can retry.
Settlement notification
Your server will need to listen for settlement notifications sent by Trust Payments. These will come in the form of POST requests that require your server to respond with an HTTP 200 OK response as soon as possible to confirm receipt.
The most important fields to check in the notification are:
- transactionreference — Unique reference assigned by Trust Payments that identifies the transaction.
-
settlestatus — The transaction state:
- If settlestatus=100, funds have reached your virtual settlement account, pending transfer to your bank, and it is now considered safe to dispatch the goods or services ordered by the customer.
- If settlestatus=3, an error has occurred that has prevented settlement. You must inform the customer that there has been a problem with their order and offer assistance to resolve the issue to their satisfaction.
In this context, when discussing the virtual settlement account, we are referring to a dedicated account held by a Trust Payments partner and managed on your behalf, which is used to collect and hold your transaction funds before they are disbursed to your nominated bank account. If the customer has successfully authorised the transaction with their bank, the transaction will update to Settle Status = 100, once the funds have reached the virtual settlement account.
Once the Settle Status for a given transaction is 100, you can expect funds to be transferred within 24 hours, typically overnight.
As part of the standard Pay by Bank flow, the customer will need to sign into their online banking account or banking app, review details of the purchase and authorise the transfer. Like with any checkout process, it is entirely possible for the customer to be delayed or fail to complete these steps. For example, they might have forgotten their bank PIN or password, or they may have simply changed their mind.
Regardless of the reason, the customer can always try again later, which would create a new transaction with a different Transaction Reference. Pay by Bank transactions that have been abandoned in Settle Status = 10 will be automatically cancelled after 7 days.
No, although the customer is always free to change their mind and select another payment method or exit the checkout entirely before they authorise the transfer.
Designing the customer experience
As your customers may be unfamiliar with Pay by Bank, and how it can streamline their checkout experience, we recommend emphasising this on your checkout and highlighting the convenience Pay by Bank can provide, as research has shown that customers are more likely to engage with novel methods of payment — specifically, that if your customer is at your checkout on their mobile device, they can complete a purchase using the banking app installed on the mobile device, meaning they do not need to enter card details. The process is as simple as signing into their banking app to authorise the transaction, which typically involves entering a PIN or unlocking using biometric authentication, such as a built-in fingerprint reader or facial recognition.
We also recommend that you advise customers, who have opted to pay using Pay by Bank, that they agree to share their bank details with Trust Payments if prompted to by their bank, in order to help better facilitate back-office processes.
Managing your transactions in Portal
As with any other payment method, all Pay by Bank transactions can be viewed and managed within Portal. When working with Pay by Bank transactions, please be aware of the following:
Testing
You will need to test your solution before you can begin processing live payments. Test transactions are processed through your test Site Reference.
Requirements
You will need to contact our Support Team and request that your test site reference is configured to connect directly to the sandbox environment. Testing frameworks and sandboxes will be arranged individually with each of our participating merchants.
When performing test transactions, the redirect URL returned in the AUTH response will redirect your browser to the sandbox environment to simulate the Pay by Bank checkout process. We will provide you with test credentials needed to proceed through the interface.