Skip to main content
Every processor returns decline codes in different formats. PayNext normalizes these into a unified system so you get consistent analytics, predictable retry logic, and clear decline reasons regardless of which processor handled the payment. When a payment doesn’t succeed, PayNext returns a status and status_reason:

Payload Example

Response Fields

Available Codes

Standard declines are listed below. Authentication-specific codes are covered in Incomplete Payments.
Subscription Impact: When a recurring (MIT) payment is blocked via workflow, the associated subscription is immediately cancelled—no retries are attempted. PayNext sends a subscription_v2.cancelled webhook and stops scheduling future payments. Review your workflow conditions carefully to avoid unintended cancellations.
payment_method_disabled means PayNext never contacted the processor. The saved payment method can’t be charged—either the customer revoked its mandate, or neither the card nor its network token is usable. The message field tells the two apart. There is no processor decline behind it, so retrying the same payment method always produces the same result. Collect a new payment method instead. See Payment Methods.
For do_not_try_again declines like expired_card or invalid_card_number, the customer must provide a new payment method. Use Recover Subscriptions for subscription renewals or the SDK checkout for one-time payments.

Incomplete Payments

Payments that require customer authentication (Cash App, Venmo, cards with 3DS) can end as incomplete if the customer doesn’t finish the flow.

Response Example

For card payments with 3DS, additional context is available in the three_d_secure object. See 3D Secure for details.
If 3DS credentials are misconfigured, you receive a failed payment. See Configure External 3DS Per Processor to update the configuration.

Network Code Mapping

PayNext automatically maps raw Visa and Mastercard response codes to standardized decline reasons: