This page helps you build a structured, thorough test plan that exercises your full payment lifecycle. Every partner has a different business model, payment mix, and regional requirements, so treat this as a framework to build on, not a fixed script. Valpay is happy to review your planned test coverage.
Cover the full lifecycle
Test the complete transaction lifecycle, both client-side and server-side. At a minimum, cover:
Successful authorizations.
Refused and declined payments.
3D Secure 2 authentication where applicable.
Webhook receipt and processing.
Captures, automatic and manual.
Full and partial refunds.
Cancellations and reversals.
Tokenization and stored payment methods, if you use them.
Your integration should never assume every payment succeeds. Handle the different result codes and refusal reasons that Adyen returns. See Payment Lifecycle States for what each state means.
Successful authorization and result codes
Make a payment with a test card and confirm you handle the final state result codes correctly:
Authorised: payment succeeded. If you use manual capture, you still need to capture it.Refused: payment was refused. You also receive arefusalReason.Error: an error occurred while processing.Cancelled: the payment was cancelled before completion.
You may also see intermediate codes such as Received, Pending, or PresentToShopper for asynchronous methods. Rely on the AUTHORISATION webhook for the authoritative outcome, not the result code alone.
3D Secure 2
Use Adyen's 3D Secure 2 test cards to exercise authentication. See Test Cards and the Adyen 3D Secure 2 testing page for the card list.
Challenge flow: the shopper completes a challenge. When prompted for a text challenge, use password
passwordfor web and mobile browser flows, or1234for native app flows. Use any other value to fail the challenge.Frictionless flow: authentication completes without shopper interaction beyond a device fingerprint.
The result codes
RedirectShopper,IdentifyShopper, andChallengeShopperindicate the authentication path your integration must handle.
If you use the Sessions flow, Drop-in or the Component handles the challenge and frictionless actions for you. If you use the Advanced flow, test that your code handles the action object returned in the /payments response.
Modifications and webhooks
Test each modification and confirm the matching webhook arrives and is processed:
Capture:
CAPTUREwebhook (test full, partial, and multiple partial captures).Cancel:
CANCELLATIONwebhook.Refund:
REFUNDwebhook (full and partial).Reversal:
CANCEL_OR_REFUNDwebhook.
For webhooks, confirm that:
They are delivered to your endpoint and you return HTTP
200.Events such as
AUTHORISATION,CAPTURE,REFUND, andCANCELLATIONare processed correctly.Duplicate webhooks are handled idempotently.
Failure to process webhooks correctly is one of the most common causes of production issues.
Edge cases and failures
Intentionally test failure scenarios and confirm your application handles them gracefully with clear messaging:
Invalid card details and expired cards.
Insufficient funds and other refusals.
Authentication failures.
Failed captures and refunds, which Adyen can simulate using specific
holderNamevalues.Network or timeout conditions where applicable.
Production readiness
Before requesting production access, confirm:
All intended payment methods have been tested independently. Methods differ in webhook behavior, settlement timing, and refund or dispute handling.
Webhooks are fully validated.
Error handling and retry logic are implemented.
Logging is sufficient for troubleshooting.
If you have unique workflows such as subscriptions, split payments, or delayed captures, contact your Valpay implementation contact to review your approach before going live.