The following guidelines are intended to help you build a structured and thorough testing plan.
Please note:
Each of our partners has different business models, payment flows, supported methods, and regional requirements. Because of this, we cannot provide a single testing guide that covers every possible use case. This section is meant to serve as a general framework that you can build on top of based on your specific implementation.
We are always ready to discuss your testing scenarios and review your planned test coverage to ensure your integration is production-ready.
Recommended End-to-End Testing Approach
We recommend testing your full transaction lifecycle, including both client-side and server-side components.
At minimum, your testing should cover:
• Successful authorizations
• Refused/declined transactions
• 3D Secure (SCA) authentication flows where applicable
• Webhook receipt and processing
• Captures (automatic and manual if applicable)
• Full and partial refunds
• Cancellations / reversals
• Tokenization / stored payment methods (if used)
Ensure your system properly handles different result codes and refusal reasons returned by Adyen. Your integration should not assume all payments are successful.
Webhook Validation
Webhooks are a critical part of the Adyen integration. During testing, confirm that:
• Webhooks are successfully delivered to your endpoint
• Your endpoint returns a proper HTTP 200 response
• Events such as AUTHORISATION, CAPTURE, REFUND, and CANCELLATION are correctly processed
• Duplicate webhook handling is properly managed (idempotency)
Failure to properly process webhooks is one of the most common causes of production issues.
Edge Case & Failure Scenario Testing
In addition to successful payment flows, we strongly recommend intentionally testing edge cases, including:
• Invalid card details
• Insufficient funds scenarios
• Authentication failures
• Expired cards
• Network or timeout simulations (where applicable)
• Partial capture/refund logic validation
Your application should handle these scenarios gracefully and present appropriate messaging to the end user.
Payment Method Coverage
If you plan to support multiple payment methods (e.g., cards, ACH, local methods), ensure each method is tested independently.
Different payment methods may have:
• Different webhook behaviors
• Delayed settlement timelines
• Distinct refund or dispute processes
• Additional regulatory requirements (e.g., SCA in Europe)
Be sure your testing reflects the real-world behavior of each method you enable.
Production Readiness Checklist
Before requesting production access, confirm:
• All intended payment methods have been tested
• Webhooks are fully validated
• Error handling and retry logic are implemented
• Logging is sufficient for troubleshooting
Collaboration & Support
If you have unique workflows (subscriptions, split payments, marketplace flows, delayed captures, etc.), please reach out to your ValPay implementation contact.
We are happy to review your testing approach, discuss edge cases, and ensure your integration is aligned with both ValPay and Adyen best practices before going live.