# Payment lifecycle

## Two statuses, two different questions

The top-level `status` tells you whether the API request succeeded. The transaction’s `data.status` tells you whether the payment is pending, successful, or failed. Manual verification is a separate workflow.

| Value | Meaning |
| --- | --- |
| `status: "success"` | The API request was accepted or processed successfully |
| `data.status: "pending"` | Payment has not reached a final successful state |
| `data.status: "success"` | The transaction is recorded as successful |
| `manual_verification_status` | The current evidence review state; not proof of funds |

## Hosted checkout flow

1. Create an order on your server.
2. Open hosted checkout for your customer.
3. Verify the notification and reconcile payment status.

After the customer pays, checkout may request a screenshot, a UTR, or additional documents. Browser OCR helps read details; it cannot confirm receipt of money.

## Evidence matching

The evidence workflow compares UTRs and recipient UPI details with eligible orders. Missing, conflicting, masked, or ambiguous details can require manual review. A screenshot can match an order without the payment being confirmed.

Use the [v2 evidence endpoint](/payment-evidence/) for its documented evidence contract. The [v1 screenshot endpoint](/submit-screenshot/) remains a distinct compatibility flow with different fields and responses.

## Complete the order once

Verify callbacks, query status where needed, and enforce idempotency in your own ledger and fulfillment logic. A duplicate webhook or a repeated status check must not credit a customer twice.

## Handle missing notifications

Use the [recovery guide](/recovery/) to reconcile records when your server is unavailable or delivery is delayed.