Testing your integration

Everything on this page applies to the test environment. Real cards are not accepted there, and none of these cards work on live.

Test cards

Any of the cards below produces an approved authorization. Use the 3DS column to pick a card that does or does not trigger a 3D Secure challenge.

Visa

Card Number	Expiry Date	CVV2/CVC3	3DS
4111 1111 4555 1142	03/2030	737	⨯
4917 6100 0000 0000	03/2030	737	✓

MasterCard

Card Number	Expiry Date	CVV2/CVC3	3DS
2222 4000 7000 0005	03/2030	737	⨯
5454 5454 5454 5454	03/2030	737	✓

Maestro

Card Number	Expiry Date	CVV2/CVC3	3DS
6771 7980 2100 0008	03/2030	737	✓

Testing Declined Payments

The cards above always result in an approved authorization. There are no test card numbers that are always refused. Instead, the test environment lets you ask for a specific refusal on the request itself.

Payment Gateway

On the /payment endpoint, add requestedTestAcquirerResponseCode to the request. The authorization is refused with the matching reason, and you receive exactly what a real decline produces: a Refused result and an Authorization webhook with success: "false".

{
  "terminalIdentifier": "1adfe4a1b2c3",
  "amount": 1000,
  "currency": "ISK",
  // ...
  "requestedTestAcquirerResponseCode": "6"
}

requestedTestAcquirerResponseCode	Refusal reason (reason on the webhook)	Result code
1	—	Authorised
2	Refused	Refused
5	Blocked Card	Refused
6	Expired Card	Refused
8	Invalid Card Number	Refused
9	Issuer Unavailable	Refused
11	3D Not Authenticated	Refused
12	Not enough balance	Refused
20	FRAUD	Refused
24	CVC Declined	Refused
0	Unknown	Error
22	FRAUD-CANCELLED	Cancelled

Any value from 0 to 46 is accepted; the full list is in Adyen's test result codes.

The field only works in the test environment. Sending it to the live environment is rejected with error 2028.

Adyen Components

Enable the cardholder-name field in the component and type a trigger value such as CARD_EXPIRED or NOT_ENOUGH_BALANCE as the name. See Test refusal reason on the Adyen web integration page for the setup and the full list of values.

Hosted Checkout, Straumur Components and Payment Links

A decline cannot be forced in these flows today: the test cards always approve, the checkout request has no equivalent field, and the card form has no cardholder-name field to carry a trigger value. Test your decline handling through the Payment Gateway — the webhook payload is identical — and read the behaviour below to know what to expect when a real shopper is declined. If you need a decline exercised in a hosted flow on staging, contact developers@straumur.is.

What to Expect

• On the Hosted Checkout page, the shopper sees a decline message and can immediately try again with a different card in the same session — a decline does not end the session.
• Checkout Status Request will keep returning New after a decline. There is no distinct "Refused" status — the session only becomes Completed once a payment succeeds, or Expired once the session times out. Don't use this endpoint to detect a decline.
• The Authorization webhook event is where a decline actually shows up: you'll receive it with success: "false" and a reason describing why (e.g. Refused, Expired Card, Not enough balance). See that page for a full example payload.
• Because the shopper can retry, a single checkoutReference can produce multiple Authorization webhook events. See One checkout, several Authorization events for both sequences and how to handle them.

Wallets in test

Apple Pay

To test Apple Pay you need to create a Sandbox on your own mobile device. For a list of test cards and instructions on how to add them to your device, please reference Apple Pay Developer Documentation - Sandbox Testing.

Google Pay

To test Google Pay it is possible to add real cards to the wallet on your device and make payments that way. Those payments are only test payments and will not be charged.

Another simple way to test is to enroll your wallet in Google's Test card suite, which provides pre-configured test cards for different scenarios.

Webhooks in test

Register your endpoint in the test portal and verify signatures with the test HMAC key. Test webhooks behave exactly like live ones, including the retry schedule, so the handler you verify here is the one that goes live. Use the test cards above to produce Authorization, Capture and Refund events, and check that each one arrives once and verifies.