About Payvendors
A payments company from Jaipur, built like a railway timetable.
Payvendors runs everyday payments for people — recharges, bills, train, flight and hotel bookings — and the collection, payout and settlement rails that businesses build on. One ledger sits underneath both, and it writes a receipt for everything.
What we do
Two kinds of traffic, one junction
For people
Consumer services with a receipt at the end of each one.The junction
A shared ledger records every request from either side, assigns a reference, tracks the state as the rail reports it, and prints the receipt. Support reads from the same ledger, so what you are told on the phone is what the system knows.- One reference per request
- States written as reported
- Receipts you can look up later
- Support with ledger access
For businesses
Collection, payout, settlement and support built as one integration.
How the platform is organised
The junction, drawn to scale
Consumer rails on one side, business rails on the other, and the ledger where they meet.
- Consumer rails
- Mobile recharge, Bill payments, Train booking, Flight booking, Hotel booking
- Business rails
- Payment gateway, Payouts, Settlement, Support portal
- The junction
- A shared ledger that records every request and issues the receipt, plus human support.
Operating principles
Four rules we keep
- 01
Transparency before confirmation
Fees, taxes and timing are shown before you confirm anything. If a figure is not known, the screen says so instead of guessing.
- 02
A receipt for everything
Every request — successful, failed or reversed — produces a reference you can look up later. Status words come from the ledger, not from marketing.
- 03
Human support
A person in Jaipur answers the phone and the inbox during published hours and can trace a reference themselves.
- 04
Sandbox honesty
Every demonstration on this website is labelled as one. Nothing here moves money, books a seat or stores what you type.
How we work
Product, engineering, operations
What each part of the team is responsible for — described as capabilities, without numbers we cannot show you.
Flows that end in a receipt
Every consumer and merchant flow is designed backwards from the receipt: what must a person be able to prove afterwards? That shapes which fields we ask for, which states we show and which words we use.
- 01Amounts, fees and taxes shown before confirmation, never after.
- 02Status words that match the ledger: queued, confirmed, failed, reversed.
- 03Indian formats by default — ₹ with en-IN grouping, IFSC, UTR, PNR, circles.
One payment, end to end
How a payment moves through the junction
The same five stops whether it is a ₹199 recharge or a merchant settlement.
Request
A recharge, bill, ticket or merchant order arrives with the details needed to carry it: who, what, how much.
Check
The request is validated against the service's rules — number format, biller, fare, limits — and the full amount is shown.
Route
On confirmation the request is placed on the right rail: an operator, a biller, a booking system or a bank transfer.
Confirm
The rail answers. Success, failure or a wait state is written to the ledger exactly as received.
Receipt
A reference, the final status and the amount are printed on a receipt that can be looked up later or reconciled against a bank statement.
Payvendors is based in Jaipur, Rajasthan. The office address, phone number and working hours are on the contact page.
Contact the teamSee the junction working.
Every flow on this website is a sandbox demonstration you can click through end to end.