Change the request before you send it again
A rule the merchant configured refused the payment. The rule is deterministic, so the identical request is refused again.
Your answers so far
- What came back from the payment?
- A refusal by the merchant's own rules. Change
Choose one
What to build
Don't retry unchanged. For an address or security code rejection, ask the customer to correct what they typed and send a new payment. For a review decline, the reviewer's answer stands, and a new attempt is a new transaction. For a screening stop, the merchant's operator can see which rule fired on the transaction record; nothing changes until they act on it.
What this means for PCI
This is guidance rather than a compliance determination. Which questionnaire you are eligible for depends on your full environment, so confirm it with your QSA or your acquirer before you rely on it.
Worth knowing
- Identical retries in quick succession are exactly the pattern a velocity rule exists to catch, so a retry loop can lock out a legitimate customer.
- CV_REJECTED is the one refusal where the issuer approved and placed a hold before the merchant's address or security code rule refused the payment. The platform releases that hold with an automatic reversal, so confirm the reversal before you tell the customer nothing was held.
- SCREENING_UNAVAILABLE is the exception to all of this: an external screening provider didn't answer, and a later retry can succeed with no change to the request.
- Show the customer the generic result message. The specific rule that refused them isn't something to publish to the person it stopped.