Skip to main content
A shopper’s card is declined by the issuer or acquirer. This is a normal outcome, not an error — RadiumOne returns it as a successful HTTP response so your code can’t miss it by only checking for HTTP-level failures.
TL;DR — 201 with data.status: "DECLINED" is final for that request_id. Replaying the same key returns the same decline; a genuinely new attempt (another card) needs a new request_id.

When this happens

The issuer or acquirer refuses the payment during a purchase, authorize, or standalone-refund call.

What you see

What to do

1

Branch on status, not the HTTP code

A decline is a 201 — the same status code as an approval (API reference):
Check data.status === "DECLINED" in the body; don’t infer anything from the 201 alone.
2

Show a generic message

Don’t surface response_code or any other host-internal detail to the shopper. Use a generic message like “Your payment couldn’t be completed. Try a different card.” — see Decline codes.
3

Treat it as final for this attempt

Don’t retry the same request_id hoping for a different result — a replay returns the identical decline. If the shopper wants to try again with a different card, that’s a new attempt: mint a new request_id.

Test it

Use the decline test cards in Test your integration to exercise this path in sandbox.

Decline codes

The full decline-handling reference: messaging, retry guidance, and webhook events.

Charge or authorize a payment

The full decline response shape.

Problem format and retries

Errors are a different thing entirely — see how they differ from a decline.
Last modified on September 15, 2026