Integration Checklist

Trustly has designed its sandbox and live modes to function in parity. Prior to going live, Trustly requires access to the sandbox for all merchants. When the items described below are validated, the integration is certified to go live in production. To flip the switch, simply go through each item in the checklist.

Requirements Checklist

Front-End/Back-EndCategoryTest Case DetailsInputOutput
FEPresentmentDemonstrate Online Banking payment mark placement with Trustly approved UX.Preview merchant’s site.
FEPresentmentSecurity SliderConfirm that the logo and short name is correct.Security slider must match Trustly approved UX
FEPresentmentUsage of Trustly hosted assets (where applicable):
-payment mark
-bank icons & logos
-footer, etc.
Preview merchant’s site.
FEPerform Deferred bank authorization for initial/first time transaction for a purchase or to fund an accountLaunch JS SDK (or native SDK). Walk through lightbox and successfully select bank accountTransaction ID retrieved
FEPerform a subsequent transaction with account on file or a purchase or to fund an account.Complete a subsequent transaction with account on file.
BothAccount on file - refresh requiredTrigger expired split token with notification: SW057 status + 326 error. Implement refresh a bank token: On-file transactionsPW: ExpiredSplitToken
Demo Bank > enter 'ExpiredSplitToken'
BothRefresh required to account on fileTrigger null/invalid split token with notification: SW051 status + 380 error
Refresh a bank token: On-file transactions
Pass in a null value for splitToken with the Capture API.
BothRefresh required to account on fileTrigger HTTP 400 bad request + 200 error in the body + message in the body from API response. Refresh a bank token: On-file transactionsThere are various methods to trigger HTTP400. Trigger one of these use-cases in the capture call:
1. PW: Expired SplitToken Demo Bank > enter 'ExpiredSplitToken' > Verification flow > exit Trustly Lightbox > initiate another capture to trigger HTTP400 status.
2. Truncate transactionId OR
3. Pass in invalid amount (ie. '10' or '10.00000') OR
4. Pass in null splitToken
BothNotify user -adverse actionTrigger Adverse Action Language with thirdPartyDecline:
Fraud Analysis: SW054 status + 390 error
Fraud Analysis: Negative Data: SW055 status + 390 error
PW: tckerror
Demo Bank > enter 'tckerror' >select SW054 associated with bank account or select SW055 associated with bank account.
BothTrigger Invalid Account use-case: SW056 status + 330 errorPW: tckerror
Demo Bank > enter 'tckerror' >select SW056 associated with bank account.
BEDemonstrate Risk data passed in the establish.Required Risk Data (if collected during registration):
phone number
Encrypted SSN/taxID (no special characters including "-"
BEIf passing in SSN, demonstrate attribute is encrypted and no special characters.
BEPerform a payout transaction.Merchant/operator approves the payout. Merchant pushes transaction to Completed status in Merchant Portal to receive the notifications.
BEIf calling Cancel API, perform a Cancel call.Merchant to Post Cancel
BEIf calling Refund API, perform a Refund call.Merchant to Post Refund
BEDemonstrate handling of webhook notifications and time-outs of notification.
BEIdempotencyMerchant to confirm they are passing unique Merchant Reference value for all transactions