> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Razorpay audit profile, Vortex IQ

> What the Vortex IQ Razorpay health audit checks: Razorpay: Authorisation, Settlement, Disputes & Payments-to-Revenue

**[Nerve Centre KPIs](/nerve-centre/kpi-cards/razorpay) · [Audit Profile](/nerve-centre/kpi-cards/razorpay/audit) · [Sentiment Settings](/nerve-centre/kpi-cards/razorpay/sentiment)**

Razorpay state matters when it's tied to captured revenue and checkout friction. This audit answers: (1) is the API key pair valid and the environment (test/live) correct, (2) is the success rate holding and which rail (UPI / card / net-banking) is driving declines, (3) are refunds, chargebacks, disputes and settlement timing under control, and (4) does payment friction map to lost revenue and support load via the commerce + support siblings.

## What this audit checks

### Authentication & access

* Key pair valid (Basic auth probe on /v1/payments?count=1)
* Key environment matches intent (rzp\_live\_ in production, rzp\_test\_ in sandbox)
* Key has read scope for payments, settlements, refunds and disputes

### Transaction health

* Success rate below 90%
* Decline rate above 8% (and which error\_reason codes dominate)
* A payment method authorising below 85% (rail-specific breakage: UPI vs card vs net-banking)
* 3DS / OTP challenge abandon rate above 30% (added friction / abandonment risk)

### Refunds & disputes

* Refund rate above 8% of volume
* Chargeback rate above 0.9% (network monitoring-programme threshold)
* Dispute rate above 1%
* Disputes approaching respond\_by deadline with no evidence submitted

### Settlement timing

* Average settlement time above 5 days (cash-flow risk vs T+2/T+3 schedule)
* Oldest pending payout above 5 days
* A settlement in failed status

### Cross-channel: payments-to-revenue (the killer area)

* Failed-payment shoppers opening support conversations (sibling support\_helpdesk) - friction driving support load
* Razorpay captured volume vs commerce-sibling order revenue mismatch > 2% (reconciliation gap)
* Refund spike correlated with a commerce returns spike in the same window
* Decline-rate spike during a campaign push (paying for traffic that can't pay)

## Data sources

* `GET https://api.razorpay.com/v1/payments` - Volume / success / decline / method mix / decline reasons
* `GET https://api.razorpay.com/v1/settlements` - Settlement timing / pending payout age
* `GET https://api.razorpay.com/v1/refunds` - Refund rate / refund volume
* `GET https://api.razorpay.com/v1/disputes` - Dispute rate / chargeback rate / reason mix