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-End

Category

Test Case Details

Input

Output

FE

Presentment

Demonstrate Online Banking payment mark placement with Trustly approved UX.

Preview merchant’s site.

FE

Presentment

Security Slider

Confirm that the logo and short name is correct.

Security slider must match Trustly approved UX

FE

Presentment

Usage of Trustly hosted assets (where applicable):
-payment mark
-bank icons & logos
-footer, etc.

Preview merchant’s site.

FE

Perform Deferred bank authorization for initial/first time transaction for a purchase or to fund an account

Launch JS SDK (or native SDK). Walk through lightbox and successfully select bank account

Transaction ID retrieved

FE

Perform a subsequent transaction with account on file or a purchase or to fund an account.

Complete a subsequent transaction with account on file.

Both

Account on file - refresh required

Trigger expired split token with notification: SW057 status + 326 error. Implement refresh a bank token: On-file transactions

PW: ExpiredSplitToken
Demo Bank > enter 'ExpiredSplitToken'

Both

Refresh required to account on file

Trigger 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.

Both

Refresh required to account on file

Trigger HTTP 400 bad request + 200 error in the body + message in the body from API response. Refresh a bank token: On-file transactions

There 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

Both

Notify user -adverse action

Trigger 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.

Both

Trigger Invalid Account use-case: SW056 status + 330 error

PW: tckerror
Demo Bank > enter 'tckerror' >select SW056 associated with bank account.

BE

Demonstrate Risk data passed in the establish.

Required Risk Data (if collected during registration):
externalID
name
address
email
phone number
enrollDate
DOB
Encrypted SSN/taxID (no special characters including "-"

BE

If passing in SSN, demonstrate attribute is encrypted and no special characters.

BE

Perform a payout transaction.

Merchant/operator approves the payout. Merchant pushes transaction to Completed status in Merchant Portal to receive the notifications.

BE

If calling Cancel API, perform a Cancel call.

Merchant to Post Cancel

BE

If calling Refund API, perform a Refund call.

Merchant to Post Refund

BE

Demonstrate handling of webhook notifications and time-outs of notification.

BE

Idempotency

Merchant to confirm they are passing unique Merchant Reference value for all transactions


Did this page help you?