Key concepts

Understanding the core components and security models that power Trustly Pay by Bank solutions can be helpful before you integrate with Trustly.

The Trustly model (A2A)

Trustly operates on an Account-to-Account (A2A) model. Unlike credit card networks that rely on intermediaries (schemes, acquirers, issuers), Trustly uses Open Banking APIs to connect merchants directly to the consumer's bank account.

  • No Chargebacks: Because the consumer authenticates directly with their bank, payments are verified and significantly harder to dispute than card transactions.
  • Push Payments: In most workflows, the consumer pushes funds to merchants, rather than merchants pulling funds from a card number.

The Lightbox

The Trustly Lightbox is the secure, hosted user interface where all consumer interactions occur. It is the only component your user sees during the transaction.

  • Bank Selection: Users select their financial institution from a dynamic list.
  • Authentication: Users log in using their familiar online banking credentials (username and password, biometrics, or multi-factor authentication).
  • Authorization: The user explicitly consents to the payment or data sharing.

To learn how to render the Trustly Lightbox, see Integrate the client-side SDK.

You must always load the Trustly Lightbox script directly from trustly.one. Do not download, bundle, or host the script from a custom domain, as this breaks security signatures and future updates.

Security and tokenization

Trustly employs a multi-layered security model that combines tokenized credentials with cryptographic signatures to protect sensitive banking data and verify request authenticity.

Split Token architecture

Trustly uses a unique split token model to ensure security. When a user connects their account:

  1. Merchant Token: Merchants receive a token representing the user's identity.
  2. Trustly Token: Trustly retains a token representing the bank connection.

A transaction can only be authorized when both tokens are present. This means that even if a merchant's database is compromised, the tokens held by the merchant cannot be used to move money without the matching Trustly half.

Request signatures

To prevent man-in-the-middle attacks, all redirects (to and from the Trustly Lightbox) and asynchronous notifications (Webhooks) are secured with a request signature. Merchants must verify this signature using their secret API key to ensure the request genuinely originated from Trustly.

Transaction types

Understanding the difference between transaction types is critical for choosing the right integration workflow.

  • Deposit (Pay-in): Moving funds from the consumer to the merchant.
  • Payout (Pay-out): Moving funds from the merchant to the consumer.
    • Used for gaming withdrawals, gig-economy salaries, or refunds. (See Send payouts)
  • Retrieval (Data): Fetching read-only data without moving money.
    • Used for identity verification (Know Your Customer), balance checks, or account ownership verification. (See Retrieve data)

Event notifications (Webhooks)

Because bank payments can be asynchronous (taking seconds to days to settle), Trustly relies on webhooks to keep merchant systems synchronized.

Instead of polling the API, merchants provide a notificationUrl. Trustly sends a JSON payload to this URL whenever a transaction state changes. For example, from Pending to Completed or Denied. Listening to these events is the only reliable way to track the final status of a payment.

For configuration details and example payloads, see Handle webhooks.