Welcome to our Trustly Integration Test Cases! These tests are designed to be simple and developer-friendly, helping you ensure your payment system is strong and reliable. Dive in now to make your integration seamless and your transactions smooth!
Triggering test cases
Each test case can be triggered in the Trustly Checkout, after bank selection. Simply mark the box named “Set order options”, and you will be presented with the test cases available for your specific API call.
Test cases for each API method:
Deposit test cases
D1 - Complete Order but Fail and Debit Immediately After Crediting
Objective:
To validate your system's ability to handle situations where a debit notification is received shortly after a credit notification, indicating that the funds for the deposit did not settle. This test simulates a rare but possible scenario in a live environment.
Scenario:
-
A deposit transaction is completed, and your system receives a credit notification from Trustly, suggesting that the funds have been credited.
-
Shortly after, a debit notification is received, indicating that the funds did not settle.
Importance:
-
Handling Post-Credit Debits: This test ensures that your system can handle unexpected debits following a credit, a key aspect of managing financial risks and maintaining transaction integrity.
-
Operational Flexibility: Tests your system's ability to respond flexibly based on whether the order can be stopped or the funds can be recovered.
-
Real-World Scenario Simulation: Although rare, this scenario simulates a situation that could occur in a live environment, where debits might follow credits due to various reasons.
Expected Outcome:
-
Your system should acknowledge the credit notification with an "OK" response.
-
Upon receiving the debit notification:
-
If you can stop the order or adjust the user's balance (in case the user holds a balance on your side) to recover the funds, respond with "OK".
-
If the order has already been processed and dispatched, and you cannot recover the funds, respond with "FAILED".
-
Verification:
-
Credit Notification Response: Confirm that your system responds with "OK" to the credit notification. Verify via Trustly Backoffice.
-
Debit Notification Handling:
-
If possible to stop the order or adjust the balance, verify that the system responds with "OK" to the debit notification.
-
If the order is irreversible and funds cannot be recovered, verify that the system responds with "FAILED". Verify via Trustly Backoffice.
-
Implementation Considerations:
-
Flexible Transaction Management: Implement logic that allows for flexibility in handling orders based on the transaction status, especially in cases of unexpected debits.
-
Timely Response to Notifications: Ensure that your system can quickly and accurately respond to both credit and debit notifications.
-
Risk Management Strategies: Develop strategies to manage risks associated with unsettled funds, such as holding periods before finalizing orders or maintaining reserve funds.
By conducting test case D1, you ensure that your system is prepared to handle complex scenarios where transactions might not go as initially indicated, and can respond appropriately based on the operational capabilities and limitations at the time of the debit notification.
D3 - Delay the Credit Notification for 60s
Objective:
To ensure that your system correctly handles delayed credit notifications from Trustly. This test is designed to simulate a real-world scenario where credit notifications are not always immediate and can be subject to various delays.
Scenario:
-
A deposit transaction is initiated, and the system is expecting a credit notification from Trustly.
-
Instead of receiving the credit notification immediately, there is a deliberate delay of 60 seconds before the notification is sent to your system.
Importance:
-
Asynchronous Processing: This test verifies that your system can handle asynchronous notifications effectively. Since Trustly operates on an asynchronous model, notifications about credit might not always align with expected timelines.
-
Realistic Simulation: In live environments, credit notifications can be delayed significantly, sometimes up to 1-2 business days. Your system needs to be prepared to handle such delays without impacting the transaction integrity or user experience.
-
Resilience to Delays: Ensuring your system remains functional and responsive even when notifications are delayed is crucial for maintaining a reliable payment processing environment.
Expected Outcome:
-
Your system should successfully receive the delayed credit notification and process it correctly.
-
Upon receiving the credit notification, regardless of the delay, your system should respond with an "OK" to Trustly, acknowledging the receipt and successful processing of the notification.
Verification:
-
System Response: Verify that your system logs or otherwise acknowledges the receipt of the delayed credit notification.
-
Acknowledgment to Trustly: Check that an "OK" response is sent back to Trustly after processing the delayed notification. This is crucial as it informs Trustly that the notification has been received and handled.
Verify via Trustly Backoffice.
Implementation Considerations:
-
Timeout Settings: Ensure that your system's timeout settings for receiving notifications are configured to handle delays beyond the usual immediate response timeframe.
-
Notification Processing Logic: Your logic for processing notifications should be independent of their arrival time. The system should be equipped to process notifications correctly, regardless of when they are received.
By conducting test case D3, you validate that your system is equipped to handle one of the critical aspects of real-world operations with Trustly – dealing with asynchronous and potentially delayed notifications in a robust and reliable manner.
D4 - Fail Payment Before It Is Confirmed
Objective:
To validate that your system correctly handles a scenario where a payment is canceled before it is completed. This test ensures that your system appropriately responds to cancel notifications from Trustly.
Scenario:
-
A deposit transaction is initiated via Trustly.
-
Before the transaction is completed and confirmed, it is canceled, triggering Trustly to send a cancel notification to your system.
-
It's important to note that a cancel notification can be sent after a pending notification, indicating that even if the transaction appears to be in progress (pending), it can still be canceled.
Importance:
-
Handling Cancellations: Ensures your system can handle transaction cancellations gracefully, which is a common occurrence in payment processing.
-
Flexibility in Transaction States: The ability to process cancel notifications even after receiving a pending notification tests the flexibility and robustness of your system in handling varying transaction states.
-
User Experience and Data Integrity: Correct handling of cancel notifications is essential for maintaining accurate transaction records and providing a good user experience.
Expected Outcome:
-
Your system should acknowledge the receipt of the cancel notification and update the transaction status accordingly.
-
An "OK" response should be sent back to Trustly to confirm that the cancel notification has been received and processed.
Verification:
-
System Response: Check that your system logs the cancel notification and updates the transaction status as canceled.
-
Acknowledgment to Trustly: Verify that your system sends an "OK" response back to Trustly, indicating successful processing of the cancel notification.
Verify via Trustly Backoffice.
Implementation Considerations:
-
Notification Processing Logic: Implement logic to handle different types of notifications (pending, credit, cancel, etc.) and ensure the system can transition between these states smoothly.
-
Transaction State Management: Ensure that your system can update the transaction state to "canceled" upon receiving the cancel notification, even if a pending notification was received earlier.
-
Error Handling and Recovery: In the case of canceled transactions, your system should be able to handle any necessary rollback or recovery actions, such as refunding the customer or updating the order status.
By conducting test case D4, you ensure that your payment processing system is equipped to handle transaction cancellations effectively, a crucial aspect for maintaining transaction integrity and providing a seamless user experience.
D5 - Do Not Deliver the Pending Notification Until the Credit Notification is Delivered
Objective:
To test the system's capability to correctly process a scenario where the pending notification is delivered after the credit notification. This tests the resilience of the integration to handle out-of-order notification delivery.
Scenario:
-
A deposit transaction is initiated through Trustly.
-
In this test case, the credit notification (indicating that the payment was successful) is sent before the pending notification (which typically indicates that the transaction is in process).
Importance:
-
Handling Out-of-Order Notifications: This scenario is critical to ensure your system can handle notifications that arrive out of the typical order. In a real-world scenario, network delays or other issues could cause such an occurrence.
-
Transaction Status Accuracy: Ensures that the system accurately reflects transaction status even when notifications arrive in an unexpected order.
-
System Robustness: Increases the robustness of your payment processing system by ensuring it can handle atypical scenarios without error.
Expected Outcome:
-
The system should correctly process the credit notification as a successful transaction, even though it arrives before the pending notification.
-
The system should also handle the subsequent pending notification correctly without altering the already successful state of the transaction.
-
For both notifications, the system should respond with an "OK" to Trustly, acknowledging their receipt and successful processing.
Verification:
-
Correct Processing of Notifications: Verify that the system processes both the credit and pending notifications correctly, maintaining the transaction status as successful after the credit notification.
-
Acknowledgment Responses: Check that the system sends an "OK" response back to Trustly for both notifications, indicating successful processing.
Verify via Trustly Backoffice.
Implementation Considerations:
-
Notification Order Independence: Ensure that the system’s logic for processing notifications does not depend on the order of their arrival. The handling of each notification type should be independent and idempotent.
-
Transaction State Management: Implement robust transaction state management to prevent the status of a transaction from being incorrectly altered by late-arriving notifications.
By conducting test case D5, you confirm that your system can correctly handle payments even when notifications from Trustly are received in an unexpected order, a key aspect for ensuring reliability and accuracy in transaction processing.
Withdraw test cases
W1 - Simulate the Money Being Returned After an Executed Withdrawal
Objective:
To confirm that your system can accurately handle a scenario where funds from a completed withdrawal are returned to the Trustly account, simulating a bounced payment or a withdrawal reversal.
Scenario:
-
A withdrawal transaction is initiated, and the funds are sent from the Trustly account to the bank account.
-
Subsequently, the bank withdrawal is returned to the Trustly account, which could happen due to various reasons like bank errors, account closure, or incorrect account details.
Importance:
-
Handling Bounced Payments: Ensures your system can process the reversal of a withdrawal transaction when the funds are returned to the Trustly account.
-
Crediting User Account: Validates that the end-user’s account or order is correctly credited with the amount from the returned withdrawal, maintaining accurate account balances.
-
Operational Resilience: Enhances the resilience of your financial operations by preparing for and effectively managing returned payments.
Expected Outcome:
-
Your system should process the debit notification (indicating funds are debited due to the withdrawal) and respond with an "OK".
-
Upon the return of the funds, your system should also process the subsequent credit notification (indicating the funds are credited back) and again respond with an "OK".
-
The end-user's account should be updated to reflect the return of the funds.
Verification:
-
Debit Notification Response: Confirm that your system has received the debit notification and responded with an "OK". Verify via Trustly Backoffice.
-
Credit Notification for Returned Funds: Ensure that when the funds are returned, the system processes the credit notification and responds with an "OK". Verify via Trustly Backoffice.
-
Account Balance Adjustment: Verify that the end-user’s account/order is accurately credited with the amount of the returned withdrawal.
Implementation Considerations:
-
Notification Processing Logic: Develop logic to distinguish and appropriately handle debit and credit notifications related to the same transaction.
-
Accounting Accuracy: Ensure that your accounting systems reflect the reversal of funds accurately and in a timely manner.
-
User Communication: Consider whether automated communications should be sent to the user to inform them of the status of their withdrawal and the return of funds.
By conducting test case W1, you assess the robustness of your payment processing system in dealing with withdrawals that are returned, ensuring that your system can handle such exceptions smoothly and maintain accurate financial records.
General test cases
G1 - Send All Order Notifications with Bad Signatures
Objective:
To ensure that your system is capable of detecting and rejecting Trustly notifications with invalid signatures. This test simulates a security scenario where notifications might be tampered with or forged.
Scenario:
-
Trustly sends various order notifications (such as pending, credit, or cancel notifications) with intentionally invalid signatures.
-
The system is expected to verify the authenticity of each notification using Trustly’s public key.
Importance:
-
Security and Fraud Prevention: This test is crucial for ensuring that your system can identify and reject fraudulent notifications. Verifying signatures is a primary line of defense against potential security breaches or fraudulent activities.
-
Integrity of Transaction Processing: Ensuring that only legitimate notifications from Trustly are processed is vital for maintaining the integrity of your transaction processing system.
-
Compliance with Best Practices: Signature verification is a standard practice in secure API integrations and is essential for complying with security best practices.
Expected Outcome:
-
The system should identify the notifications with bad signatures as invalid.
-
Instead of responding with "OK", the system should reject these notifications, possibly with an error message indicating the reason for rejection.
Verification:
-
Signature Verification Logic: Ensure that your system correctly implements the logic for verifying signatures using Trustly’s public key.
-
Rejection of Invalid Notifications: Check that your system does not process notifications with invalid signatures and does not respond with "OK" to these notifications.
Verify via Trustly Backoffice.
Implementation Considerations:
-
Robust Signature Verification: Implement robust signature verification logic that rigorously checks the authenticity of each notification.
-
Error Handling: Ensure that your system has appropriate error handling for scenarios where signature verification fails. This might include logging the incident and alerting relevant personnel.
By conducting test case G1, you verify that your system is equipped with essential security measures to identify and reject fraudulent notifications, thereby safeguarding the integrity and security of your transaction processing.
G2 - Double-Deliver All Delivered Notifications
Objective:
To validate that your system can correctly handle the scenario of receiving duplicate notifications from Trustly. This test simulates the situation where notifications might be sent twice due to network errors or other communication issues.
Scenario:
-
For every notification type (such as pending, credit, or cancel notifications), Trustly sends each notification twice.
-
This simulates a situation where Trustly resends a notification because it did not receive a response to the initial notification, possibly due to a network error.
Importance:
-
Handling Duplicate Notifications: Ensures your system can appropriately handle duplicate notifications without processing the same transaction more than once.
-
Maintaining Consistent Responses: Validates that your system consistently responds to repeated notifications, a crucial aspect in maintaining idempotent operations.
-
Robustness Against Network Errors: Tests the resilience of your system against common network issues that could result in duplicate message delivery.
Expected Outcome:
-
The system should identify and process each unique notification only once, regardless of how many times it is received.
-
For every duplicate notification, the system should send the same response as it did for the first delivery of that notification.
-
The system should not perform duplicate actions (like double-crediting an account) based on receiving the same notification more than once.
Verification:
-
Duplicate Notification Handling: Verify that your system can recognize and appropriately handle duplicate notifications.
-
Consistent Response: Check that the system responds identically to each duplicate notification, sending an "OK" response if that was the response sent the first time.
-
Transaction Integrity: Ensure that the transaction is registered only once in your system, regardless of the number of times the notification is received.
Implementation Considerations:
-
Idempotency in Notification Processing: Implement idempotent processing logic to ensure that the same notification processed multiple times does not result in repeated transaction actions.
-
Response Tracking: Your system should track responses sent to Trustly so that the same response can be sent for duplicate notifications.
-
Logging and Monitoring: Maintain logs of all notifications and their processing status to aid in identifying and handling duplicates.
By conducting test case G2, you ensure that your system is resilient to common network issues, capable of handling duplicate notifications efficiently, and maintains transaction integrity even in scenarios of repeated message delivery.
G3 - Complete Order but Do Not Load SuccessURL if Successful
Objective:
To ensure that your system correctly processes a transaction as successful based on the receipt of the credit notification from Trustly, regardless of whether the SuccessURL is loaded or not. This test simulates scenarios where the SuccessURL is not visited due to user action or technical issues.
Scenario:
-
A deposit transaction is successfully completed via Trustly.
-
However, the SuccessURL is not loaded. This could happen if the user closes their browser immediately after completing the deposit, or if a technical issue prevents the SuccessURL from being visited.
Importance:
-
Independence from SuccessURL: Verifies that your system does not rely on the loading of the SuccessURL to consider a transaction successful.
-
Handling User Behavior and Technical Issues: Tests your system's ability to handle realistic user behaviors and technical glitches where the SuccessURL might not be visited.
-
Correct Transaction Status: Ensures the transaction is considered successful based on the receipt of the credit notification, which is the reliable indicator of transaction completion.
Expected Outcome:
-
The system should mark the transaction as successful upon receiving the credit notification from Trustly, independent of the SuccessURL being loaded.
-
The transaction processing logic should not be contingent on the user visiting the SuccessURL.
Verification:
-
Transaction Status Check: Verify that the transaction is marked as completed or successful in your system once the credit notification is received, even if the SuccessURL is not loaded.
-
No Dependency on SuccessURL: Ensure that there is no logic in your system that depends on the redirection to or loading of the SuccessURL for transaction completion.
Implementation Considerations:
-
Notification-Based Transaction Completion: Implement logic that bases the completion and success of a transaction solely on the receipt of the appropriate notifications (like the credit notification) from Trustly.
-
Separation of UI and Transaction Logic: Keep user interface elements (like the SuccessURL) separate from the core transaction processing logic to ensure transaction integrity.
-
Robust Error Handling: Incorporate error handling for scenarios where the SuccessURL might not be visited, ensuring that such situations do not impact the transaction status.
By conducting test case G3, you validate that your system correctly identifies and processes transactions as successful based on Trustly's credit notifications, thus ensuring robustness and reliability in handling a variety of real-world scenarios.