payment_reversed webhook

On the rare occasions that a customer reverses a payment, you now receive [a webhook] after payment_settled informing you when the reversal happens.

Value-based settlement notifications

You can now configure creditable notifications to arrive a certain amount of time after payment settlement for only transactions above a value that you choose.

For example, you might only add the post settlement delay for payments above £500 in value. This means that high-value payments are much less likely to be reversed after you receive a creditable webhook, but the instant experience is not lost for lower-value payments.

PLN merchant accounts

We now support merchant accounts in the PLN currency, accessible via Console.

Note that the PLN currency is only usable with Payouts.

AIS + PIS flow for React

To make the user experience simpler, you can now give your user the option of creating an additional Data connection when they consent to a payment. This flow appears for some German banks when your user would need to input an IBAN at the authorisation stage.

Custom statement references

When you create a payment, you can now fill in the statement_reference field inside the beneficiary object. This controls what your customer sees on their bank statement, in the ‘reference’ field, after a closed-loop payment.

If you leave this field empty, a random 18-character string appears on the end user's bank statement. Therefore, we strongly recommend that you include a useful reference value in this field.

New functionality for payment cancellation in Ireland

If a payment in Ireland is not yet authorised, you can now call the /cancel endpoint up to and including the authorised status. This brings the functionality of this endpoint for Irish payments in line with the UK.

Payouts reliability improvements

We've addressed an edge case where a payout creation request could return a 202 status code but fail silently without creating a resource. This scenario now correctly causes a 500 status code.

AIS + PIS flow for Android and iOS

To make the user experience simpler, you can now give your user the option of creating an additional Data connection when they consent to a payment. This flow appears for some German banks when your user would need to input an IBAN at the authorisation stage.

Console changes — metadata in reports

You can now include metadata fields in the Merchant Account Transactions reports that you download from Console.

If you want to include this information in reports, click the cog icon at the top of the Merchant Account historical balances table, on the Merchant Account tab.

creditable_at in GET Payment requests

You can now see when a payment was considered creditable when you make a successful GET Payment request (with a 200 code). This value displays when your payment reaches the executed status or later.

Scheme_id no longer provided in provider selection

You no longer need to pass a scheme_id within the provider_selection object when you create a payment.

Instead, to specify a particular payment scheme, use the scheme_selection object and set the type value to preselected.

Scheme_id now provided with payouts when you call the merchant-account/{id}/transactions endpoint

When you call the /transactions endpoint, if a payout or refund has executed, you now receive the scheme_id to indicate what scheme the payout was made through.

Credit notifications for suspense accounts

You can now use credit notifications (the payment_creditable webhook) alongside pre-settlement verification. This means that you receive a payment_creditable webhook only if pre-settlement verification is complete.

Authorisation expiry for Signup+ in Finland

If you are making a Signup+ payment in Finland, you can now receive the authorization_expired error response if a payment expires, alongside authorization_expired webhooks.

Scheme selection for payouts

You can now choose how a payout settles using scheme selection. You can select a payment scheme for your payout by using the scheme_selection object inside the Create payout request.

Retry options removed for new UIs (web SDK and hosted page) when retry isn’t available

In some geographies, payment retries are not supported yet. When you do not pass a retry object in a payment request, the UI changes to remove actions that your user cannot perform without retries.

First-party webviews now supported by Web SDK

The Web SDK is now compatible with first-party webviews.

Payout and refund metadata from the merchant account /transactions endpoint

When you call the /transactions endpoint, you can now see the metadata associated with any payouts or refunds.

NRB supported in payments requests

NRB is now a type of account_identifier that you can use in payouts to an external account.

Provider availability webhook

When a provider changes status (from healthy to unhealthy or vice versa), you now receive a webhook which describes the event.

Note that TrueLayer UIs all automatically indicate, and disallow users from selecting, unhealthy providers.

iOS SDK v3.2.0

If there is an issue meaning that the iOS SDK isn’t available, it now falls back to the HPP in a web view to ensure a payment is always possible.

See the iOS SDK release history.

Android SDK v3.2.0

If there is an issue meaning that the Android SDK isn’t available, it now falls back to the HPP in a web view to ensure a payment is always possible.

See the Android SDK release history.

Transactions table in Console

On August 5th, we updated the Transactions table accessible through the merchant account dashboard. These updates include quality of life improvements, such as infinite scrolling and improve accessibility support. Additionally, you can now query a date range rather than seeing transactions for a single day.

Console user interface update

The user interface and navigation experience in Console has been updated, along with several other changes. The Console-related documentation on this site has also been updated.

In addition to the visual update, there are also new features:

• You can click the initial in the top-left corner to switch between the organisations you're a member of.
• In the Settings page within an app, you can enable or disable legacy products and features.

Provider icon styles

When you make a request to any provider-related endpoints, such as /v3/payments-providers/search or /v3/payments/{id}/authorization-flow, you can now specify the type of icon you want to receive for the banking providers.

The available options are:

• default: The bank logo in SVG format with no background.
• extended: The bank logo in SVG format with a solid background colour.
• extended_small: The bank logo in JPEG format with a solid background colour with 192x192px dimensions.
• extended_medium: The bank logo in JPEG format with a solid background colour with 432x432px dimensions.
• extended_large: The bank logo in JPEG format with a solid background colour with 864x864px dimensions.

Read more in our docs on how to get information about providers.

Bank Identification Numbers in /payments-providers/search response

The response from the /v3/payments-providers/search endpoint now includes a bin_ranges array, which contains a full list of the Bank Identification Numbers used by the provider. This typically refers to the first 8 numbers on cards issued by the provider.

Start authorization_flow at payment creation

We've added documentation for a new authorisation flow you can use as part of a direct API integration. In a direct API integration, you previously had to use the /v3/payments/{id}/authorization-flow endpoint to start the sequence of requests and responses that authorised a payment.

You can now use the authorization_flow parameter when you create a payment to start the authorisation flow. You provide the same information in. the authorisation_flow parameter as you do in the /v3/payments/{id}/authorization-flow endpoint.