A financial account with a provider: for example, a current account.
A process that ensures only the bank account owner can authorise access to their account.
A token that carries the necessary information to access a resource directly. When a client passes an access token to a server managing a resource, that server uses the information contained in the token to decide whether the client is authorised.
Access tokens usually expire after one hour, though this depends on the provider.
Account Information Services. Regulated providers (like TrueLayer) access a customer’s bank account data, so that the provider can offer services to that customer. They must have permission to do this.
Account Information Service Provider. A company authorised to access bank account data with the explicit consent of your user.
The server-side integration to use if you want to build your own UI, integrate into your existing UI, or want more flexible customisation options.
Allows open banking-enabled services to offer a much simpler and faster authentication flow to users, via their mobile device.
Account Servicing Payment Service Provider. A company that provides and maintains a payment account for a payer.
A process in which a consumer logs in to online banking to create a secure connection between their bank and a third party provider.
A method by which a bank allows their users to authorise a payment. Right now we support
embedded authorisation flows, but we may support more in the future.
The secure service hosted by TrueLayer that allows users to authenticate with their credentials. It also has API endpoints that you can use to obtain and renew an
The bank account that receives money when a payment is made.
Business Identifier Code. A number used to identify a specific bank as part of an international transaction. Also known as a “SWIFT code”.
A pair of .pem files — one public, one private — used to sign requests. These are also known as signing keys.
An application that implements our APIs.
With a closed-loop withdrawal, you can send funds to an account that your user has previously made a deposit from.
Information which identifies you or your user. This can include a username and password, API keys, a pair of certificates, etc.
The online journey a user makes when they consent to a third party provider accessing their account information.
There are three types of consent flow in the UK & Europe:
The payment limits defined in the mandate.
Our developer portal, where you can get your
client_secret, use our auth link builder, and get an
The TrueLayer product that provides access to your users' financial data.
An authorisation flow which requires you to present input fields to your user and submit their values to our API, to authorise a payment.
A web UI that makes it easy to accept payments from your users.
This feature allows safe retries if a request fails (as long as the key is valid) while only performing the requested action once. Enabled using the
International Bank Account Number. A number that identifies a bank account, used for international transactions.
The agreement between you and your user which enables you to take payments from their account.
A tool that allows you to view reports about your incoming and outgoing payments, for internal monitoring or reporting purposes.
Our software development kit for iOS and Android allows you to quickly add open banking payments to your app. Our mobile SDKs integrate with our Payments API.
Open banking involves giving regulated companies secure, limited, authorised access to user bank accounts, so that those companies can provide useful services.
A way for your customers to pay using bank transfers from any provider that TrueLayer is connected with.
With an open-loop withdrawal, you can send funds to any account. Useful for sending funds to your bank account, or to a user's account that hasn't previously been used to deposit funds.
A legacy payments product. Offers open-loop and closed-loop payments, verified payouts, merchant account access and automated sweeping.
The latest version of our Payments API.
A value which indicates where a payment is in its life cycle.
An amount of money paid out to a person or group.
Payment Initiation Services. Gives regulated providers authorised access to a customer’s bank account to make payments on the customer’s behalf. The customer must give consent for this. See open banking payments.
Payment Initiation Service Provider. Initiates account-to-account payments with the explicit consent of the user.
A bank or other financial institution that provides TrueLayer with access to financial data through APIs.
A screen used by your users to select their bank. Use the
providers endpoint to build this.
The second Payment Services Directive. European legislation which enables regulated third party providers (including TrueLayer) to access a user's bank account information and/or request payments, with the user's consent.
A Payment Services Provider. An entity that carries out regulated payment services.
Payment Service User. Any user who can make a payment through your customer interface is a PSU. In our documentation, PSU refers to your user.
Using machine learning to automatically classify transactions from a given bank account into groups. For example, purchases can be sorted into utilities, work expenses, travel or groceries.
An authorisation flow which requires you to redirect your user to their bank's website or app to authorise a payment.
When initiating a payment with the
redirect authorisation flow, this redirects the user back to your app or website after they have authorised a payment with their bank.
A token you need to get a new access token. Usually used to get a new access token after the previous one has expired, or to get access to a new resource for the first time.
Refresh tokens expire until the user needs to reconfirm consent (usually after 90 days). If not used, they expire after 30 days.
The bank account which makes a payment. This is usually your user's bank account.
See redirect URI.
A testing environment in which you can test your integration without using live bank accounts.
Strong Customer Authentication. A security requirement introduced to cut down on payment fraud online. It requires that all digital payments must go through an authentication process that proves the payer is who they say they are and is authorised to use the account.
In this process, the user must confirm two of three criteria:
- something only the user knows (eg a password)
- something only the user possesses (eg their phone via their mobile phone number)
- something the user is or has (eg via touch or Face ID).
Sort Code and Account Number. Bank details used to identify accounts in the UK and Ireland.
A set of permissions that the user grants to the client so that the client can access data on their behalf.
Our product which simplifies onboarding by allowing a user to register with a single payment.
Society for Worldwide Interbank Financial Telecommunication. An organisation that facilitates international payments and assigns Business Identifier Codes (BICs), also known as “SWIFT codes”.
Account information and payment initiation service providers that are authorised by the FCA.
Your customer. See PSU.
Enables third party providers like TrueLayer to make payments on behalf of a user at variable amounts and intervals. The user gives consent, sets limits for these payments and authenticates the payment mandate with their bank upfront. Payments are then initiated automatically on a regular basis.
Our product that verifies a user by comparing your customer's name with bank records, then assigning a
Variable recurring payments (VRPs) made between consumers and businesses.
A type of variable recurring payment (VRP) enabled by a legal provision called sweeping, which enables some third party providers to make payments between accounts owned by the same user.
Updated 9 days ago