This page has been deprecated and will be removed in the near future. If you are looking for information regarding your Trustly certification or launch checklist, please reach out to your account manager or [email protected]
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.
|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):|
-bank icons & logos
|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
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):|
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|
Updated 2 months ago