For non-United States payments please use the Trustly Europe connector.
Setup
When setting up Trustly in the dashboard, configure the following credentials, which can all be obtained from Trustly after the account has been created.- Access ID - The identifier that acts as a username when connecting to the Trustly API.
- Access Key - The key that acts as a password when connecting to the Trustly API.
- Merchant ID - The ID that is used to target the specific merchant account to process payments for.
Integration
Redirect integration
The default integration for Trustly is through a redirect to a hosted payments page.- Redirect
- Webviews (mobile)
Start by creating a new transaction with the following required fields.After the transaction is created, the API response includes a Redirect the buyer to the
POST /transactions
payment_method.approval_url and the transaction is set to buyer_approval_pending.approval_url (open in a browser or Webview) so they can complete authentication and approve the payment.
After approval the buyer is redirected to the redirect_url provided when creating the transaction.
Do not rely solely on the redirect — either poll the transaction or (recommended) rely on webhooks to detect the final status (for example capture_succeeded or failure states).
In sandbox, use the Demo Bank and any credentials to simulate a successful flow.Direct integration
Trustly provides web and mobile SDKs for an in-context (direct) integration. For these flows, indicate the platform by setting an appropriateintegration_client
when creating the transaction, and then build a client-side integration that uses the POST /transactions/:transaction_id/session API to initialize the Trustly SDK.
To start, create a new transaction with the appropriate integration_client.
session_token which can be used to get the session data for that transaction.
establishData required to load the Trustly SDK.
View a complete, ready-to-run example for direct Trustly Web SDK integration on GitHub. The repository includes setup instructions, session initialization, sample client code for loading the Trustly script, and guidance for handling redirects and webhooks.
Limitations
- Most API calls in Trustly are asynchronous and therefore captures and refunds are in a pending state until a notification is received. It’s important to set up webhooks from the environment to yours in order to be notified of these status changes.
- Partial refunds are supported. However, another refund cannot be initiated while there is an outstanding in-progress refund.
Recurring payments
This connector supports recurring payments via the API and via Embed. If using Embed, most of the complexity is handled, but for direct API integrations it’s important to ensure the right recurring payment flags are sent on the initial and subsequent payments.Initial payment
For an initial recurring payment, please make sure to use a suitablepayment_source (either recurring or card_on_file)
and the merchant_initiated and is_subsequent_payment flags are set to false. This ensures a customer-present flow is
triggered and a payment method is created that keeps track of Trustly’s split token.
POST /transactions
Subsequent payment
For a subsequent recurring payment, please make sure to use the samepayment_source (either recurring or card_on_file)
and the merchant_initiated and is_subsequent_payment flags are set to true. This ensures a customer-not-present flow is
triggered with the stored split token.
POST /transactions
Renewing split token
In some situations, a recurring payment may fail because the Trustly “split token” has expired.refreshSplitToken on a new customer-present transaction. It is important in this request to
set a redirect_url to redirect the user back to the site after they have approved the transaction.