Test with Cards

Test cards

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

• Expiry: any future date (e.g. 12/26)
• CVC: any 3-digit number (e.g. 123)
• Postcode: any value

Simulate a successful payment

Simulate a declined payment

Test 3D Secure authentication

For the complete list of Stripe test cards, see Stripe'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 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.

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

• Test with Open Banking → - simulate Open Banking payments using Yapily Mock
• Test with Super Credit → - simulate Buy Now, Pay Later payments.
• Test with Webhooks → - verify your webhook endpoint handles events correctly