Tringify for Razorpay declares all five payment operations: charge, status, cancel, refund and refund_status. It holds merchant credentials and reads payment and refund results directly from Razorpay. Tringify owns attempt state, payment recording, checking and decisions about excess or late money.
Charge reuses the Razorpay order whose unique receipt identifies the same payment session. Its provider notes bind the store, session, order and immutable checkout details. The reply returns the Razorpay order ID as provider_session_id and the reviewed Standard Checkout browser action. Checkout receives a timeout in seconds from the remaining expires_at. An expired attempt is refused. The adapter stores no payment or refund outcomes. Its short credential claim prevents replacing credentials during charge dispatch.
Every status call fetches /orders/{id}/payments using the provider_session_id supplied by the platform. Authorised payments are captured first. A paid response includes every captured transaction, including a transaction Razorpay has already refunded, with exact decimal amount and ISO currency. For example, 42.50 in USD stays 42.50, never a floating point approximation. Razorpay exposes payment created_at but no separate capture timestamp; this stable provider payment time is returned as captured_at in RFC 3339 UTC. Store-facing timestamps are formatted by Tringify in the store timezone. Do not treat that timestamp as an exact capture-processing time.
Razorpay cannot cancel an order. Cancel therefore answers the same status shape as status. A cancel request may arrive before charge has returned its provider reference; that valid optional-reference request answers pending rather than inventing a final outcome. A failed individual payment leaves a retryable order pending. The checkout timeout closes the normal payment window; browser timer suspension and late provider settlement can still produce a late capture. The platform continues checking and decides whether captured money pays the order or is refunded. A provider timeout, invalid response or unavailable account returns an unavailable response, never a made-up failed payment.
Refunds use refund_id as the Razorpay X-Refund-Idempotency header and in refund notes. Retrying the same refund returns the same provider refund; changing its payment or amount is a conflict. Razorpay enforces the remaining refundable balance. Refund status reads the provider refund ID when known or searches the named payment by the refund ID. Missing or uncertain outcomes remain pending; the app never creates a replacement refund during a status check. A known refund state, including failed, is an HTTP 200 refund_status response. A refused refund dispatch is a definite 4xx; an unavailable status read is 503.
Razorpay webhook signatures are checked against the raw body before using any entity or notes. A verified event names a payment attempt or refund and sends an empty-body authenticated wake to /payment-sessions/{id}/wake or /payment-refunds/{id}/wake. A payment event without session notes is correlated through its Razorpay order notes. A webhook sends no outcome and updates no payment record. A failed wake is refused for redelivery; the platform still checks without webhooks. Use the store-specific webhook URL shown by the app. Storeless webhook and old shopper confirmation URLs are removed.
Shopper completion verifies the encrypted checkout context, origin and Razorpay signature and asks Tringify to check the attempt. Returning from a provider window does not prove payment. Credential rotation keeps previous accounts available for earlier status and refund reads. The adapter supports up to 32 saved unpurged account records for a store and refuses overflow visibly. Status and refund lookup work is bounded, and unreadable provider state is reported as unavailable. No provider reconciliation cron or outcome report queue is required.
Store API clients, MCP connectors, themes, webhooks and CSV consumers use Tringify payment and refund records. They must not infer a paid order from a browser result, issue a provider capture themselves or expect Razorpay outcome callbacks to modify records. The platform learns results through signed provider calls. The same order/refund state and wording apply in Store Admin and the mobile app.