Storefront checkout
A hosted or embedded checkout that returns the customer to your order page with a payment id and a receipt.
- Order → payment → webhook
- Retry with another method on failure
- Receipt link for the customer
Payment gateway
Accept payments with a checkout that explains itself.
UPI, cards, net banking and wallets behind one order object. Every payment ends with an id, a signed webhook and a receipt your customer can read — and on this page, every step is a labelled simulation.
checkout · Test merchantSandbox demo
Amount due
₹1,250.00
demo_order_7k3q9z1
- UPI
- Cards
- Net banking
- Wallets
Sandbox · no money moves
Try it
Pay with sandbox details and watch the request travel.
Switch methods, use the published test card, or flip the decline switch to see how a failure is reported.
Demo checkout
Sandbox demoDemo environment — no real transaction is performed.
Pick a method, pay with sandbox details and watch the request travel. No bank, card network or UPI app is contacted.
Route of the request
- Order createdWaiting
- RoutedWaiting
- AuthorisedWaiting
- CapturedWaiting
The receipt and webhook appear here after you pay.
Supported methods
Four ways to pay, one order object.
How each method confirms, described without success-rate claims.
| Method | How the customer pays | Confirmation | Notes |
|---|---|---|---|
| UPI | Collect request to a UPI ID, or a QR / intent on mobile | After the customer approves in their UPI app | Best default for Indian checkouts |
| Cards | Debit and credit cards with issuer authentication | After the issuer authorises | Card details are tokenised, not stored by you |
| Net banking | Redirect to the customer's bank and back | When the bank returns a success response | Bank list shown is configurable |
| Wallets | Pay from a prepaid wallet balance | Immediately on wallet approval | Enabled per wallet provider |
Smart routing
One junction, several routes.
A payment can be sent down more than one route to the same destination. When a route degrades, traffic moves — this drill shows the idea, not live traffic.
Why route at all
Routes differ by method, bank and time of day. Choosing per payment keeps a single slow route from holding up every checkout.
What you see
Nothing changes in your integration. The payment id, webhook and receipt look the same whichever route carried it.
Simulated failover drillAll four routes carrying traffic.
Use cases
Built for how Indian businesses actually collect.
Subscriptions and SaaS
Create orders on a schedule from your billing system and reconcile each one by its idempotency key.
- Idempotent order creation
- Payment status by API
- Statement lines per invoice
Marketplaces
Collect on behalf of sellers and hand the money onward with payouts that share the same ledger.
- Order notes carry the seller id
- Payouts reference the order
- One settlement statement
Fees and admissions
Collect fees against a student or applicant reference with a receipt the family can keep.
- Reference captured in notes
- Partial payments as separate orders
- Downloadable receipt
Integration
Four steps from an order to a verified webhook.
Samples use a sandbox host and a pv_test_ key. Copy them as a starting point; swap the key for one from your dashboard.
- Create an orderServer-side, with an idempotency key
- Open the checkoutHosted page or embedded SDK
- Verify the signatureHMAC over the raw webhook body
- Handle the webhookMark the order paid, send the receipt
1 · Create an order
Sandbox demo
# Sandbox endpoint — illustrative, never moves moneycurl -X POST https://api.payvendors.example.invalid/v1/orders \ -u pv_test_7k3q9z1a2b3c4d5e6f7g8h9j: \ -H "Content-Type: application/json" \ -H "Idempotency-Key: demo_order_7k3q9z1" \ -d '{ "amount": 125000, "currency": "INR", "receipt": "shop-1042", "notes": { "customer": "Test customer" } }'3 · Verify the webhook signature
Sandbox demo
import { createHmac, timingSafeEqual } from "node:crypto"; // Compare against the raw request body, before any JSON parsing.export function verifyWebhook(rawBody, signatureHeader, secret) { const expected = createHmac("sha256", secret).update(rawBody).digest("hex"); const a = Buffer.from(expected); const b = Buffer.from(signatureHeader ?? ""); return a.length === b.length && timingSafeEqual(a, b);} // Express exampleapp.post("/webhooks/payvendors", express.raw({ type: "*/*" }), (req, res) => { const ok = verifyWebhook(req.body, req.get("X-Payvendors-Signature"), process.env.PV_WEBHOOK_SECRET); if (!ok) return res.status(400).end(); const event = JSON.parse(req.body); // handle event.event === "payment.captured" res.status(200).end();});Authorization
Basic auth with the key as the username and an empty password.
Idempotency-Key
Any unique string per logical order; retries with it return the original order.
X-Payvendors-Signature
Hex HMAC-SHA256 of the raw webhook body using your webhook secret.
Settlement cadence
Captured today, in your account on the configured cycle.
Settlement cycles are configured per account; we describe them rather than promise them. Every batch arrives with a UTR.
- CapturedDone
- Batched on the cycleDone
- Credited with a UTRDone
- ReconciledDone
A cycle like T+1 means payments captured today are batched and credited the next working day. The exact cut-off and cycle for your account are shown in the dashboard, not assumed here.
SANDBOX
One settlement line (sample)
- Gross
- ₹1,250.00
- Fee (sample 2%)
- − ₹25.00
- Tax on fee (as applicable)
- − ₹4.50
- Net credited
- ₹1,220.50
Illustrative rates. Your pricing is shown before you go live.
Security and controls
Controls we can describe, not badges we can't show you.
Where a certification or registration is relevant we will share the document on request from the contact page. Here are the mechanisms themselves.
Tokenised card data
Card numbers never reach your servers. The checkout exchanges them for a token your system can store safely.
Signed webhooks
Every event carries an HMAC signature over the raw body. Verify it before you trust the payload — the snippet above shows how.
Idempotent requests
Send an Idempotency-Key with order and payout creation; retries return the original object instead of duplicating it.
Scoped keys and audit trail
Separate test and live keys, dashboard roles with least privilege, and a log of who changed what.
Apply
See what we ask for before you ask us.
A transparent preview of the application. The real onboarding happens in the four-step wizard.
Apply for the gateway
Sandbox demoDemo environment — no real transaction is performed.
This form is a demonstration of the fields we ask for. It does not submit anywhere — use the wizard or the contact page for a real conversation.
FAQ
Questions, answered plainly.
Only 4111 1111 1111 1111 with any future expiry and any 3-digit CVV. The simulator checks the Luhn digit and refuses other numbers so you can see validation copy in action.
Ready when you are
Put the checkout in front of real customers when you're ready.
Start with a sandbox key from the wizard; go live from the dashboard after verification.
Sandbox keys never move money.