The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →To integrate Razorpay into a custom website, create each payment order on your server, open Razorpay Standard Checkout in the browser, verify the returned payment signature on your server, and use verified payment state and webhooks to control fulfillment. Do not put the Key Secret in frontend code or treat a success page as proof that money was captured.
This guide covers a one-time payment flow for a custom website. Account eligibility, payment methods, currencies, international acceptance, and approval requirements can vary by country and merchant account.
Choose the right Razorpay integration
Standard Web Checkout suits a custom website whose backend needs to create orders, verify payments, and coordinate fulfillment. If your site uses an ecommerce platform, check its supported Razorpay integration before building a custom gateway.
| Need | Likely option |
|---|---|
| Custom website checkout | Standard Web Checkout |
| Low-code collection or shareable payment URL | Payment Links or Payment Pages |
| Supported ecommerce platform | Platform integration or plugin |
| Recurring billing | Razorpay Subscriptions |
| Marketplace payments split among parties | Razorpay Route, subject to account eligibility |
| Invoice-based collection | Razorpay Invoices |
Razorpay lists these and other integration options in its API documentation. A Payment Link or Page may be simpler than a custom checkout, while subscriptions and marketplace payouts introduce requirements beyond a one-time payment flow. Confirm availability and eligibility with Razorpay for your account and region.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
How the payment flow works
- The customer chooses what to buy. Your server calculates the total from trusted product, tax, shipping, discount, and inventory data and creates an internal order in a pending state.
- Your server creates a Razorpay Order and stores its ID against that internal order.
- The browser opens Razorpay Checkout using the public Key ID and server-created Razorpay Order ID.
- Checkout returns payment, order, and signature values to the browser. The browser sends them to your server; they are not proof of payment on their own.
- Your server verifies the signature and checks the provider order, amount, currency, and payment state against its own records.
- Your server records capture and uses webhooks to reconcile asynchronous events. Fulfill only when your trusted backend state meets your payment policy.
Razorpay’s Standard Checkout guide and web integration steps assign order creation, signature verification, capture, and webhook handling to the merchant.
Prerequisites
- A Razorpay merchant account; live payments require account activation and applicable business verification.
- A server-side backend or serverless function. A static site may launch Checkout, but cannot securely create trusted orders, keep secrets, verify signatures, or handle webhooks by itself.
- A database or other durable store for internal orders, provider order and payment IDs, and event processing state.
- HTTPS, a valid TLS certificate, correctly resolving DNS, and a publicly reachable webhook endpoint for production.
- Separate test and live credentials, plus a fulfillment process that tolerates delayed and repeated notifications.
These are consistent with the prerequisites in Razorpay’s Standard Checkout documentation. Payment integration does not by itself settle your separate tax, consumer-protection, privacy, refund, record-keeping, or compliance responsibilities.
Set up Test Mode and protect API keys
Use Test Mode credentials for simulated transactions; Live Mode credentials are for real payments. Treat the environments, their keys, orders, dashboard data, and webhooks as separate. The Key ID is used in browser Checkout configuration; the Key Secret stays on the server and must never be committed to source control or sent to a browser.
Razorpay’s documented Dashboard wording is broadly Switch to Test Mode → Account & Settings → API Keys → Generate Key. Labels may change; follow the current integration instructions and API authentication guide.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →RAZORPAY_KEY_ID=rzp_test_xxxxxxxxx
RAZORPAY_KEY_SECRET=xxxxxxxxxxxxxxxx
RAZORPAY_WEBHOOK_SECRET=separate-random-secretConfigure different production secrets, including a separate webhook secret. The webhook secret is not the API Key Secret. Keep both out of frontend bundles and logs.
Create an internal order and Razorpay Order on the server
Create the merchant’s own order before contacting Razorpay. Store at least an internal order ID, customer reference, amount in minor units, currency, pending status, provider order ID when available, payment ID when available, and creation time. Derive the payable amount from trusted server-side cart and pricing data; never accept the final amount simply because it arrived in a request from the browser.
Razorpay amounts use the currency’s smallest unit. For INR, that normally means paise, but do not apply an INR conversion rule to every currency. Avoid floating-point currency calculations; use integer minor units or a decimal-money library and preserve the currency alongside the amount. Razorpay documents zero-decimal currencies such as JPY and three-decimal currencies such as KWD, BHD, and OMR for relevant international-payment contexts. Check the applicable rules for your account and currency in the regional integration documentation.
const cart = await loadCartForUser(req.user.id);
const amountMinor = calculateTrustedTotal(cart); // integer minor units
const internalOrder = await createInternalOrder({
customerId: req.user.id,
amountMinor,
currency: "INR",
status: "pending"
});Then create the Razorpay Order from the backend using the server-held credentials. Razorpay documents its API base URL as https://api.razorpay.com/v1 for most resources.
import Razorpay from "razorpay";
const razorpay = new Razorpay({
key_id: process.env.RAZORPAY_KEY_ID,
key_secret: process.env.RAZORPAY_KEY_SECRET
});
const providerOrder = await razorpay.orders.create({
amount: amountMinor,
currency: "INR",
receipt: internalOrder.id,
notes: { internal_order_id: internalOrder.id }
});
await saveProviderOrderId(internalOrder.id, providerOrder.id);Return only the safe Checkout data needed by the browser: Key ID, provider order ID, amount, currency, and suitable display details. If order creation fails, keep the internal order retryable, log a redacted error, and allow a controlled retry rather than showing a success message or creating uncontrolled duplicate orders. Use your own idempotent order-initiation design; check Razorpay’s current API documentation before relying on any provider-specific idempotency feature.
Open Standard Checkout in the browser
Load Razorpay’s Checkout script and configure Checkout with the public Key ID and the Razorpay Order ID returned by your server. The amount and currency displayed must correspond to that server-created order. Razorpay’s web integration instructions show opening the Checkout instance with rzp1.open().
<script src="https://checkout.razorpay.com/v1/checkout.js"></script>const options = {
key: publicKeyId,
amount: order.amount,
currency: order.currency,
name: "Example Store",
description: "Order payment",
order_id: order.razorpayOrderId,
handler: async function (response) {
await fetch("/api/payments/verify", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(response)
});
}
};
const checkout = new Razorpay(options);
checkout.open();The handler is useful for a quick customer-facing response, but its values are untrusted input until your backend verifies them. A customer may close the browser, lose connectivity, or never reach the handler even when payment activity has occurred.
Verify the payment on your server
The Checkout response includes razorpay_payment_id, razorpay_order_id, and razorpay_signature. Verify the signature using Razorpay’s documented method and server-held Key Secret. For the standard Checkout signature, the signed message is the raw order ID, a vertical bar, and the payment ID, in that order, hashed with HMAC-SHA256. Follow the official integration steps for your chosen SDK and language.
Free tools Windows power users keep installed
One-click scans. No signup required.
import crypto from "node:crypto";
const generated = crypto
.createHmac("sha256", process.env.RAZORPAY_KEY_SECRET)
.update(`${razorpay_order_id}|${razorpay_payment_id}`)
.digest("hex");
const expected = Buffer.from(generated, "utf8");
const received = Buffer.from(razorpay_signature, "utf8");
const valid = expected.length === received.length &&
crypto.timingSafeEqual(expected, received);
if (!valid) throw new Error("Invalid payment signature");In production, prefer the Razorpay SDK helper where available and use the official verification procedure. Use the exact IDs; do not trim, reorder, or reconstruct them from display text.
After signature validation, verify that the provider order belongs to the internal order, the amount and currency match your records, and the payment has not already been processed. Check the payment’s current state before fulfillment. A valid signature establishes the integrity of the Checkout response; it does not by itself prove that the payment is captured or that the amount matches the order you intended.
Distinguish authorization from capture
An authorized payment is not the same as a captured payment. Razorpay says an authorized payment must be captured—manually through the Capture Payment API or through automatic-capture settings—and uncaptured payments may be automatically refunded after the applicable capture window. The window and rules can depend on the payment and account, so consult the current Standard Checkout guide rather than assuming a universal deadline.
Automatic capture
Automatic capture is often the simpler fit for ordinary ecommerce purchases. Your application still needs to confirm and record the resulting payment state; a browser callback alone is not a capture confirmation.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsManual capture
Manual capture can suit a workflow that needs to authorize first and capture after a review or inventory check. It requires a server-side request to POST /v1/payments/{payment_id}/capture. Plan for capture deadlines, any applicable partial-capture rules, refunds, and reconciliation before choosing this flow. Do not fulfill an order while it is merely authorized unless your business policy explicitly supports that risk.
Configure secure, idempotent webhooks
Webhooks let your server learn about payment, refund, and dispute activity independently of the customer’s browser. Configure the relevant events in the Razorpay Dashboard for the correct mode. For a basic one-time flow, consider captured-payment and failed-payment events, plus refund and dispute events where relevant.
Razorpay’s current Standard Checkout guide says webhook endpoints should respond within five seconds, recommends acknowledging with HTTP 200 before heavy work, and describes retries after failed delivery. Verify details against the current documentation when configuring your endpoint.
- Read the raw request body and the
X-Razorpay-Signatureheader. Verify the signature using the webhook secret; do not parse and reserialize the payload first if raw bytes are required for verification. - Reject invalid signatures. Store the event ID with a uniqueness constraint so a repeated delivery cannot trigger duplicate work.
- Persist the verified event durably, acknowledge with HTTP 200 promptly, and enqueue business processing for a worker.
- In the worker, validate the event against your internal order and current provider state, update the order transactionally, and make fulfillment or notifications idempotent.
Receive request → verify raw-body signature → deduplicate event ID
→ persist event → return HTTP 200 → queue work → reconcile order stateDelivery can be delayed, repeated, or out of order. Make state transitions deliberate: a refund is not a new payment, an earlier-looking authorization must not overwrite a captured state, and a failure event must not cancel a captured order without checking the actual provider state.
Best Value
- 12th Gen Intel Core i7-1255U Processor (2.80 GHz, Up to 4.70 GHz, 12M Cache)
- 14.1” LCD IPS FHD Touchscreen Display, (1920 x 1080)
- 8 GB Memory (RAM)
- 512 Solid State Drive
Test the full payment lifecycle
Razorpay Test Mode uses simulated transactions and does not move real money. Available test paths for cards, UPI, netbanking, wallets, and failures depend on the integration and account. Use Razorpay’s test instructions and integration steps for current test values and flows.
| Scenario | Expected handling |
|---|---|
| Successful card or UPI test | Verify the response, reconcile state, and fulfill only after the configured captured-payment condition is met. |
| Failed payment | Keep the order unpaid or retryable; do not fulfill. |
| Customer closes Checkout | Leave the order pending until verified provider state or a later event resolves it. |
| Browser disconnects after payment | Reconcile through webhook or a server-side provider query; do not ask for another payment before checking the original. |
| Duplicate callback or webhook | Process once using payment and event IDs plus idempotent state updates. |
| Wrong signature, order ID, amount, or currency | Reject or quarantine; never attach the payment to a mismatched order. |
| Authorized but not captured | Do not treat as captured; capture according to the chosen strategy or reconcile. |
| Refund or dispute event | Update the payment record and route disputes or failed refund handling to the appropriate review process. |
| Test deployment configured with live keys | Block deployment through environment checks and keep the mode-specific credentials separate. |
Go live safely
- Complete account activation and applicable KYC, and confirm your business and website meet Razorpay’s requirements.
- Deploy over HTTPS with valid TLS and working DNS.
- Switch the Dashboard to Live Mode and generate live API keys. Replace both test credentials in production secret storage, not in frontend code.
- Configure a separate production webhook endpoint and secret, and confirm the correct live events are enabled.
- Check which payment methods and international payments are approved for your account and intended customer locations.
- Run a controlled real transaction, verify capture, settlement and refund procedures, and confirm customer notifications and fulfillment.
- Monitor payment and webhook errors, maintain reconciliation procedures, and ensure retries cannot cause duplicate fulfillment.
Razorpay’s go-live instructions and authentication guide cover live keys and replacing test credentials. A simulated test success is not evidence that a live payment will settle. Some payment methods require account approval, and international acceptance may need to be enabled; check your account configuration and the current payment gateway guidance.
Common integration failures and recovery
Checkout does not open
- Confirm the Checkout script loaded, the public Key ID is present, and the provider order came from your backend.
- Check that the key and order are from the same Test or Live mode and that the amount and currency are valid.
- Ensure your code creates the Checkout object and calls
open(); inspect browser console and network errors. - Check that your Content Security Policy permits required provider resources. Razorpay notes that
rzp1.open()must be invoked by site JavaScript in its web integration steps.
Payment appears successful but your site shows failure
The browser callback may have been interrupted, the verification endpoint may have failed, a webhook may be delayed, or the payment may still be authorized rather than captured. Query provider state server-side and reconcile by payment ID and order ID before asking the customer to retry.
Signature mismatch
Check the correct Key Secret for the payment mode, exact order and payment IDs, signature formula, and absence of whitespace or encoding changes. For webhooks, use the separate webhook secret and required raw body.
Webhook does not arrive
Check public HTTPS reachability, TLS, DNS, firewall or WAF rules, Dashboard endpoint and mode, response time, application logs, and queue-worker health. Razorpay’s webhook guidance covers fast acknowledgment and retries.
Test works but Live Mode fails
Check account activation, live credentials, approved payment methods, production webhook setup, domain and HTTPS configuration, and any international-payment or currency restrictions. Keep a test/live deployment check so one environment cannot silently use the other’s credentials.
Quick Recap
When another option may fit better
- Quick Integration: consider it if you want a simpler setup and do not need extensive custom payment orchestration; see Razorpay’s Quick Integration guide.
- Payment Links or Pages: useful for low-code collection without a tightly integrated cart and fulfillment workflow; see the Razorpay API documentation.
- Platform integration: WordPress, WooCommerce, Shopify, Magento, and other supported platform users should check the platform-specific path linked from the Standard Checkout guide. Test plugin, theme, platform-version, cache, and webhook behavior in your own setup.
- Stripe or PayPal: evaluate them if your customer base, country, or wallet requirements point elsewhere. Confirm merchant-country and business-category availability, payment methods, onboarding, and current pricing directly with Stripe or PayPal; those details are account- and region-dependent.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
