For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Dashboard
GuidesAPI ReferenceSDKs
GuidesAPI ReferenceSDKs
  • Get Started
    • Overview and Solutions
    • Choose an Integration
    • Quickstart
    • Branding Guidelines
    • Get Support
  • Accept Payments
    • Instant Payments
    • Trustly Pay
    • Recurring Payments
    • Scan and Pay
    • Remember Me
    • Payment Integration Checklist
  • Send Money
    • Send Payouts Using Online Banking
    • Send Payouts Using Account Information
    • International Transfers
  • Retrieve Data
    • Verify Accounts Using Online Banking
    • Verify Accounts Using Micro-Deposits
    • Retrieve Bank and User Information
    • Tokenize Bank Information
    • Trustly ID
    • Insights Data
  • Core Concepts
    • Key Concepts
    • The Establish Data Object
    • Transactions and Transaction IDs
    • Tokens and Account Security
    • Redirect URLs and Return Flow
    • Webhooks and Events
    • Content Strings
  • API Fundamentals
    • Authentication and OAuth
    • Secure Requests and Signature Validation
    • Idempotency
    • Testing
    • Status codes and type definitions
  • Manage Your Integration
    • Go-Live Checklist
    • Merchant Portal
    • Reports and Reconciliation
    • Refresh Bank Authorization
    • Override Risk Declines
    • VIP Tiers
    • Financial Institution Status
Dashboard
Products
PaymentsDataPayouts
Company
AboutCareersContact Sales

Terms of Use | Privacy Policy | © 2026 Trustly, Inc.

Developer-friendly docs for your API
GitHub|Contact Support|Business Help Center|Merchant Portal
Terms of Use|Privacy Policy|© 2026 Trustly, Inc.
Developer-friendly docs for your API
LogoLogo
North AmericaEurope
North AmericaEurope
On this page
  • Event Notifications (Webhooks)
  • Prerequisites
  • Configure your listener
  • Security
  • Event headers
  • Sandbox Event Timing
  • Event properties
  • Primary properties
  • Conditional properties
  • Event types
  • Authorize event example
  • Verify the signature
  • Available Funds Guidance
  • Event Listeners (Client-Side)
  • Supported notifications and event types
  • Listener example
  • Command and event reference
Core Concepts

Webhooks and Events

Learn about Trustly event notifications (webhooks) and client-side event listeners

|View as Markdown|Open in Claude|
Was this page helpful?
Previous

Redirect URLs

Next

Content Strings

Built with

Trustly uses two complementary event systems: server-side webhooks (Event Notifications) to communicate transaction status changes to your backend, and client-side Event Listeners to track user interactions within the Trustly Lightbox.


Event Notifications (Webhooks)

Event Notifications are Event objects pushed to the merchant server. A notification indicates changes to the object referenced in the event, such as changes to the transaction status (authorized, canceled, denied). For most use cases, receiving and processing event notifications is required to successfully integrate a Trustly product.

Trustly uses asynchronous event notifications (webhooks) to communicate transaction status. Because transfers on the Automated Clearing House (ACH) network are not instant, you cannot rely on the immediate API response to determine the final state. You must implement a notification handler to receive and process these updates.

Prerequisites

Before you can handle event notifications, ensure you have completed the following:

  • Publicly Accessible Endpoint: You must have a publicly accessible HTTPS endpoint on your server to receive POST requests from Trustly.
  • Security Configuration: You should be prepared to validate the cryptographic signature included in the request headers to ensure the notification is authentic. See Validate the notification signature.

Configure your listener

To receive notifications, you must configure a webhook listener URL. You can configure this URL in two ways:

  • Default configuration: Contact your Trustly Integration team or Support representative to configure a default notificationUrl in the Trustly administrative interface.
  • Per-Transaction: Override the default by passing a specific notificationUrl in the establishData object when you initiate a transaction. See Establish Data for more information.

Trustly sends a POST request to your endpoint with the event details. Your system must acknowledge receipt by returning a 200 OK status.

You must return HTTP status 200 OK in less than 3 seconds. If Trustly does not receive a 200 OK response in 3 seconds, we will retry the notification every 5 minutes for 12 hours.

Example Header

Authorization: Basic TThSYUhnRWpCRTU0enVGWU1SUXE6RVlOM0dYYXNyVlUxdlExdXlZejIyTk5RZHk0PQ==

Security

Ensure you verify the event notification was sent by Trustly and has not been tampered with by following the steps in Secure Requests to validate the request signature provided.

Event headers

An Event notification contains the following headers:

KeyTypeDescription
AuthorizationStringA Base64 encoded string that can be used to validate the request.
Content-TypeStringapplication/x-www-form-urlencoded

Sandbox Event Timing

In the Trustly Sandbox environment, some asynchronous notifications such as payout processing are run in batches every 300 seconds (5 minutes).

Event properties

An Event notification body is an application/x-www-form-urlencoded string containing various data points. All events contain at a minimum, the following parameters:

Primary properties

ParameterTypeDescription
merchantIdStringUnique ID assigned to the merchant associated with the event.
merchantReferenceStringA unique identifier from the merchant’s systems such as order ID or payment ID.
paymentTypeStringIdentifies the type of Payment this notification is associated with. This is provided in the establishData when the Authorization is created.
transactionTypeStringType of Transaction that this event is associated with e.g. Authorization, Capture.
eventIdStringA unique Trustly event identifier.
eventTypeStringType of Event included in this notification.
objectIdStringA unique ID that identifies this transaction. This will be the transactionId that is returned from the Trustly API or SDK.
objectTypeStringThe type of object this Event is related to.
messageStringOptional event message.
parentObjectIdStringThe unique ID of the parent object if existent.
timeZoneStringTime zone used for createdAt. This will always be Etc/UTC.
createdAtUnix TimestampThe notification creation date and time
statusIntegerTransaction status at time of event
statusMessageStringHuman readable Status message.

Conditional properties

The following properties are included on some events based on the transactionType and eventType:

ParameterTypeDescription
splitTokenStringOnly sent if enabled for the merchant. Only sent if transactionType = 1 and status = 2. Merchant must store the value and send it back on Capture API calls.
errorCodeStringError code related to the current status if the event was generated by an error status event.
suggestedRetryAmountStringSuggested amount for payment retry if the associated payment transaction failed due to spending limits or risk of insufficient funds.
paymentProviderTransaction.statusString
paymentProviderTransaction.statusMessageStringPayment provider transaction status message.
paymentProviderTransaction.reasonCodeEnumThe reasonCode should reflect more detailed information about why the transaction was not accepted successfully.
paymentProviderTransaction.reasonCodeMessageStringA more descriptive description of the event that generated the reason code.

Event types

Event TypeDescription
EstablishThe transaction was created and is awaiting user interaction.
AuthorizeThe customer successfully authorized the transaction with their bank.
DataReadyAll bank-qualified data (balance, account details) is retrieved and ready for access.
UpdateThe transaction details or status have been updated.
ProcessTrustly has submitted the transaction to the banking network for processing.
CompleteThe transaction funds have settled.
CancelA request to cancel the transaction was received.
CancelledThe transaction was successfully canceled by the user, merchant, or system.
ExpireThe transaction session expired before it could be completed.
FailedThe transaction failed (for example, due to technical errors or user abandonment).
DenyThe transaction was denied (for example, due to insufficient funds or high risk).
DisputeA dispute or chargeback was initiated for the transaction.
ReconcileThe transaction has been reconciled.
RefundA refund was initiated or processed for the transaction.
ReverseThe transaction was completed but later returned (for example, an administrative or ACH return).
RefreshThe account balance or data has been refreshed.
CONSENT_REVOKEDThe customer revoked their consent for data access or future payments (currently in development).

Authorize event example

1{
2 "merchantId": "000123",
3 "merchantReference": "unqiueTransactionIdentifier",
4 "paymentType": "6",
5 "transactionType": "1",
6 "eventId": "1028606616",
7 "eventType": "Authorize",
8 "objectId": "1024919204",
9 "objectType": "Transaction",
10 "message": "",
11 "timeZone": "Etc/UTC",
12 "createdAt": "1701986450064",
13 "accountVerified": "true",
14 "fiCode": "200005501",
15 "paymentProviderType": "PWMB",
16 "status": "2",
17 "statusMessage": "Authorized",
18 "splitToken": "CK71sLLEMRAAqahQ2BV4gDo0Duwq+aCs/LRfSDEZGOICTv9VrJXQBxAm6Mf/gGRpTLoUR7tlISHgu5P9fFG6auNEi78QTqaRRod7tfU6ywuS1cffoReSzmAv93m2RZjc="
19}

Verify the signature

To ensure the notification originated from Trustly and has not been tampered with, validate the cryptographic signature included in the Authorization request header.

See Validate the notification signature for implementation details and code samples.

Available Funds Guidance

If your merchant account is enabled for Available Funds Guidance (AFG), you can use webhook payloads to intelligently recover transactions that fail due to insufficient funds.

When a payment fails, the notification payload may contain a suggestedRetryAmount. This value represents a safe upper limit for a new transaction attempt based on the customer’s available balance at the time of the failure.

Prerequisites: Contact your Trustly Customer Success Manager or Implementation Team to enable Available Funds Guidance for your merchant account.

To implement this recovery logic:

  1. Listen for Deny or Failed events where paymentProviderTransaction.status equals SW021 (Insufficient Funds) or SW054 (Security Controls), AND suggestedRetryAmount is greater than 0.
  2. Check the payload for the suggestedRetryAmount field.
  3. Prompt the customer to retry the payment using the suggested value.

Event Listeners (Client-Side)

The Trustly SDK provides an addPanelListener function which is used to track user events within the Trustly Lightbox experience. This function is also essential for intercepting the standard browser redirects (returnUrl and cancelUrl) in order to process those final events with JavaScript callbacks directly within your Single Page Application (SPA).

Supported notifications and event types

You can use the addPanelListener function to provide a custom handler to deal with Lightbox events.

The JavaScript window event notification call below only works on native apps when the Trustly SDK is used or if the merchant implements the creation of new windows.

Listener example

1Trustly.addPanelListener((command, obj) => {
2 switch(command) {
3 case "open":
4 console.log("Lightbox will open");
5 break;
6
7 case "event":
8 switch(obj.type) {
9 case "load":
10 console.log(
11 "Lightbox page " + obj.page +
12 " finished loading for transaction " +
13 obj.transactionId
14 );
15 break;
16
17 case "bank_selected":
18 console.log(
19 "Payment provider having id " + obj.data +
20 " was selected on the page " + obj.page +
21 " for transaction " + obj.transactionId
22 );
23 break;
24
25 case "back":
26 console.log(
27 "Back button was clicked on the lightbox page " +
28 obj.page + " for transaction " + obj.transactionId
29 );
30 break;
31
32 case "close":
33 console.log(
34 "Lightbox close process was initiated " +
35 "on the lightbox page " + obj.page +
36 " with reason " + obj.data +
37 " for transaction " + obj.transactionId
38 );
39 break;
40
41 case "new_location":
42 console.log("Browser will be redirected to " + obj.data);
43 break;
44 }
45 break;
46
47 case "close":
48 console.log("Lightbox was closed");
49 break;
50 }
51});

Command and event reference

The listener receives two parameters: the high-level command (open, close, event) and the detailed object data.

Command/Event TypeCommand/Type DataDescription
open (Command)-Triggered immediately when the Trustly Lightbox opens.
close (Command)-Triggered when the Trustly Lightbox finishes closing.
event (Command)-Triggered when a specific user action or internal change occurs within the Lightbox.
load (Event){ page, transactionId }Triggered when a specific page finishes loading. page contains the name of the loaded page.
loading (Event){ page, transactionId }Triggered when page content loading is active. This can be useful for displaying spinners or progress indicators.
bank_selected (Event){ page, transactionId, data, transfer }Triggered when a user selects a bank tile. data is the paymentProviderId. transfer.paymentProvider contains the bank details (ID and name).
back (Event){ page, transactionId }Triggered when a user clicks the back button or navigates to the previous page in the flow.
close (Event){ page, transactionId, data: reason }Triggered when the Lightbox close process is initiated. reason will be "return" or "cancel".
new_location (Event){ data: newLocation }Crucial for SPA integration. Triggered when the flow is complete and the user is about to be redirected to the returnUrl or cancelUrl. newLocation contains the final URL with return parameters. You can process the final result using this data and prevent the browser redirect.