Trustly

Adapter 0.1.0, documentation reviewed 2026-10-25. Overall status: limited.

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by notificationid (EU) or eventId (North America); Trustly documents that notifications can be delivered more than once.
• Delivery order: not guaranteed by the provider.
• EU notifications are retried with the same notificationid (5 s, 15 s, 45 s, 15 min, 45 min, 90 min, then every 3 hours), and Trustly expects the same reply as the first time. Store notificationid and answer a repeat with the same signed reply without acting on it again. North America events are retried every 5 minutes for 12 hours until answered with HTTP 200 within 3 seconds; treat a repeated eventId as the same event. Account, pending and credit notifications can arrive in any order.

Known limitations

• Trustly runs separate API families: the EU JSON-RPC API and the North America REST API. Each has its own format ids, status tables and identifiers, and they are never mixed or linked to each other.
• credit and debit change the end user's balance and their meaning depends on the order they belong to. credit is shown as a received deposit (payment success), but after an AccountPayout, Withdraw or Refund on the same order it means that operation failed and the amount returned; the notification itself does not say which. debit is shown without a payment outcome because it means either a deposit taken back after it never settled or a completed withdrawal, and its effect depends on the merchant's reply, which the notification does not contain.
• pending means the end user finished the flow but the money has not been received; it is never shown as a credited payment. A Deposit result only means the order was created.
• payoutconfirmation, payoutfailed, payoutdowngraded, account, verifyAccount, assessAccount and the detailed cancel fields are opt-in, and payoutfailed and payoutdowngraded are sent in production only, so their absence in pasted data means nothing.
• Only example payoutfailed and payoutdowngraded errorcode values are documented (incorrect_account_number, sepa_instant_downgrade); other values stay unknown. ERROR_CHARGE_NOT_APPROVED and ERROR_ACCOUNT_NOT_FOUND have no documented meaning beyond their names.
• Trustly may add or remove EU error codes and GetWithdrawals transfer states without notice, and the same code can have different texts on different pages (624 means bank account number, IBAN or AccountID). Undocumented codes and states stay unknown. The HTTP status of EU errors is not documented.
• The EU error example and the KYC and Account Assessment examples in Trustly's documentation are not valid JSON (a missing brace, comments, trailing commas). Comments and trailing commas are removed with a LENIENT_JSON warning; the missing brace of the error example is not repaired, so that example is rejected as invalid JSON.
• Signatures (params.signature, alg= prefixed values, the North America Authorization header) and custom notification headers are sensitive and never verified or copied; a pasted notification is not treated as authentic.
• Merchant requests to the EU API carry the API password and are recognized but not analyzed. The merchant's reply to a notification is recognized but not analyzed.
• Only the EU methods Deposit, Refund, AccountPayout, ApproveWithdrawal and GetWithdrawals have result semantics. Other method results (for example SelectAccount, Charge or Swish) are shown as unknown. The structure of the GetWithdrawals result was not transcribed; transferstate is read from the data object or its list entries. A Refund result of 0 is not documented and stays unknown.
• EU events are linked only by orderid. messageid (the merchant reference) and enduserid are never used to link events, and enduserid is not copied. Whether a payoutconfirmation for a Refund carries the refund's own id or the deposit OrderID is not documented, so it may not link to the deposit.
• Merchant Direct Debit and Trustly Direct Debit (recurring) are only partly covered: pending, credit and cancel use the same methods, the cancel reason is shown, but the 116 scheme detail strings are not decoded and advice notifications are shown without an outcome. Recurring charges cannot be told apart from one-off deposits.
• EU pay by bank documents no chargeback or dispute notification. North America Dispute and Reverse events, status 10 Reversed, AC112 Disputed and EFT code 996 are shown as reported.
• North America event types are documented by name only, so their stage and outcome come from the documented transaction status (0 to 14) and transaction type where present; events without a status keep a conservative default. AC codes are lifecycle states shown as attributes; only AC101, AC103, AC113, AC114 and AC115 are decoded as errors.
• North America: the webhook page names application/x-www-form-urlencoded but shows a JSON example, so both are read. The field holding the extended decline reason code is not named; extended codes are decoded when they appear in paymentProviderTransaction.reasonCode. ACH return codes R01 to R84 are not enumerated, the 53 UK Direct Debit codes have no transcribed meaning except ARUDD_0 and DDICA_6, the paymentType number for Instant is not documented, and duplicate handling beyond eventId is not documented.
• North America REST errors have no transcribed example; the { message } error variant some endpoints use is not recognized. User verification error codes and the Data product are not analyzed.
• Category and retry guidance per code are PandaPayLens suggestions. System codes (SE01 to SE03) are shown as conditional retries because the outcome of the original request can be unknown.
• Sector eligibility depends on jurisdiction, licensing and Trustly's onboarding; approval for one sector does not imply another. Trustly's group companies Ecospend and SlimPay, and payabl.-wrapped Trustly payments, are out of scope.

Examples

• Trustly: payout failed: A payout accepted, then reported as failed, then the amount credited back.
• Trustly: North America payment failed: A Failed event posted as an HTTP request and decoded as insufficient funds.

Provider documentation

• EU API protocol (JSON-RPC 1.1)
• EU error handling
• EU signatures and keys
• EU notifications overview
• EU pending notification
• EU credit notification
• EU debit notification
• EU cancel notification
• EU payoutfailed notification
• EU Deposit
• EU Refund
• EU AccountPayout
• EU GetWithdrawals
• EU gaming integration (notification order)
• North America status codes and type definitions
• North America webhooks and events
• North America notification signature
• North America transactions and transaction ids

PandaPayLens is not affiliated with Trustly. Pasted notifications are never treated as verified: PandaPayLens does not check webhook signatures.