Test with Cards

Test cards

Your account is processed through either Adyen or Stripe. Expand the section that matches your account - if you are not sure which, ask your account manager.

Adyen test cards

Use any of the following card numbers in the Super payment component when testing. For all cards if not specified otherwise, use:

• Expiry: 03/30
• CVC: 737
• Postcode: any value

Simulate a successful payment

Scenario

Card number

Expiry

CVC

Payment succeeds

4111 1111 1111 1111

03/30

737

Payment succeeds (debit card)

4111 1120 1426 7661

12/30

737

📘 Note

The declined payment scenarios below are triggered by the Card Holder Name entered in the payment component.

Simulate a declined payment

Scenario

Card Holder Name

Generic decline

UNKNOWN

Insufficient funds

NOT_ENOUGH_BALANCE

Expired card

CARD_EXPIRED

Incorrect CVC

CVC_DECLINED

Card blocked

BLOCK_CARD

Test 3D Secure authentication

Scenario

Card number

3DS required - authentication succeeds

4917 6100 0000 0000

3DS required - authentication fail

Enter password incorrectly

3DS - Frictionless

5201 2815 0512 9736

Simulate a surcharge payment

Surcharging must be enabled on your brand before this scenario will work. Ask your account manager to enable it. For how surcharging works and how the surcharge is applied, see Apply a Surcharge.

Scenario

Card Holder Name

Surcharge

CORPORATE

For the complete list of Adyen test cards and regional scenarios, see Adyen's testing documentation.

Handling decline responses

When a card is declined, the API returns a 402 HTTP status. The response includes an extensions.issues object with details about why the payment failed - use these to show the customer a meaningful error rather than a generic message.

{
  "extensions": {
    "issues": {
      "declineReason": "Your card has insufficient funds.",
      "declineCode": "INSUFFICIENT_FUNDS",
      "declineClassification": "UNRESTRICTED"
    }
  }
}

declineReason is a customer-friendly description of the decline. You can display this directly in your UI.

declineCode identifies the specific reason the card was declined. The full list of possible values is:

AUTHENTICATION_REQUIRED DUPLICATE_SUSPECTED FRAUD_SUSPECTED GENERIC_DECLINE INSUFFICIENT_FUNDS INVALID_ADDRESS INVALID_AMOUNT INVALID_CVC INVALID_EXPIRY_MONTH INVALID_EXPIRY_YEAR INVALID_NUMBER INVALID_PIN MERCHANT_BLACKLIST PAYMENT_METHOD_ATTEMPTS_EXCEEDED PAYMENT_METHOD_EXPIRED PAYMENT_METHOD_NOT_SUPPORTED PAYMENT_METHOD_REVOKED PROCESSING_ERROR

declineClassification tells you whether the decline code is safe to expose:

declineReason is always safe to show to the customer regardless of declineClassification.

Use the test cards in the declined payments table above, under your processor's section, to trigger different declineCode values and verify your error handling handles each case correctly.

Testing refunds

Once you have a completed sandbox payment, you can test the refund flow either via the API or directly from the sandbox portal, see refund a payment for more.

Via the API, call POST /refunds with the transactionId from your test payment:

{
  "transactionId": "transactionId",
  "amount": 1000,
  "externalReference": "TestRefund"
}

To test a partial refund, pass an amount less than the original payment amount. To test a full refund, pass the full original amount.

Via the sandbox portal, navigate to the payment in business.test.superpayments.com, open the transaction, and initiate a refund from there.

What to verify for refunds

• The refund API returns a transactionReference
• Your webhook endpoint receives a RefundSuccess event
• Partial refunds reflect the correct remaining balance in the fundingSummary object
• Your integration handles the RefundSuccess webhook correctly - for example, updating order status or notifying the customer

What to verify

After completing a test card payment, confirm:

• The payment status from GET /payments/{transactionId} matches the expected outcome (e.g. PaymentSuccess for success, PaymentFailed for a decline)
• Declined payments are handled gracefully in your UI - the customer should see a clear error and be able to retry
• Your webhook endpoint received the correct event (PaymentSuccess or PaymentFailed)
• 3DS authentication flows complete correctly and the result is reflected in the payment status

Next steps