We never hold the sensitive part
Cashvya does not collect, transmit or store card numbers, CVVs or UPI PINs. A customer authorises every payment inside their own bank or UPI app. The most sensitive credential in a payment never touches our servers.
What we do hold is the record of a payment — amount, order reference, UPI reference number, and the customer's contact details — plus the merchant's payout bank details.
Payments are verified against the bank, not assumed
A checkout that says "payment successful" because the customer tapped a button is worthless. Cashvya marks a payment successful only after it has matched an actual bank credit notification to that payment.
- Bank notifications are read from operator-controlled channels — an SMS observer on an operator phone and a read-only connection to an operator mailbox.
- A notification is attributed to a payment by amount, time window and UPI reference, inside a bounded verification window.
- Each payment holds an exclusive slot on a receiving UPI ID for the duration of its window, so two customers paying the same amount at the same moment cannot be confused with each other.
- Duplicate notifications are detected and dropped rather than counted twice.
Credentials and access
| Credential | How it is protected |
|---|---|
| Merchant password | PBKDF2-SHA512 with a per-password salt. Never stored or logged in plain text. |
Secret API key (cashvya_live_…) | Shown once on creation; afterwards only a masked form is shown. Revealing it again requires the account password. |
Webhook signing secret (whsec_…) | Encrypted at rest, masked in the dashboard, rotatable at any time. |
| Admin console access | A 256-bit access key plus a time-based authenticator code. Two-factor cannot be skipped — an admin without it is forced to enrol before any session is issued. |
| Merchant dashboard sessions | Signed, expiring tokens. A suspended merchant's session and API key both stop authenticating immediately. |
| All secret comparisons | Constant-time, so a response cannot be timed to guess a secret character by character. |
Changing a saved payout destination requires the account password again, because redirecting future settlements is the most valuable thing a stolen session could do.
Encryption
- In transit — HTTPS with certificates from Let's Encrypt. The admin
session cookie is
HttpOnly,SameSite=StrictandSecureover HTTPS. - At rest — bank payout details, webhook secrets, one-time passcodes and OAuth tokens are encrypted with AES-256-GCM under a master key held outside the database.
- Lookups without exposure — high-entropy tokens are stored as keyed digests, so a database copy alone does not yield usable credentials.
Signed webhooks and outbound safety
Every webhook is signed with HMAC-SHA256 over the exact body sent, using your
own webhook secret, in the X-Gateway-Signature header. Verify it before trusting the
payload — see Webhooks for code.
Outbound requests are also defended:
- Webhook URLs are validated before every delivery and every retry. Loopback, private, link-local and cloud metadata addresses are refused, so a webhook URL cannot be used to reach our internal network.
- Redirects are never followed on a webhook delivery.
- Deliveries time out after 10 seconds and are retried on a fixed backoff, with each attempt recorded.
Abuse and account protection
- Sign-in attempts, passcode requests and password re-entry are rate limited and locked out after repeated failures.
- A payment session is bound to the device that started it, so a link cannot be resumed from a different device mid-payment.
- Customer-facing redirect URLs are restricted to origins the merchant owns, so a checkout cannot be crafted to send a paying customer to a phishing site.
- Merchant-supplied text is escaped rather than injected into pages, and the receiving UPI ID can only be set by the platform operator, never by a merchant.
- Sensitive actions are written to an append-only audit log.
Your part
- Keep your secret API key on your server. Never put it in a web page, a mobile app or a public repository.
- Verify the webhook signature on every delivery, and treat browser events as user-interface hints only.
- Serve your site over HTTPS and keep your webhook endpoint reachable.
- Turn on two-factor authentication for your dashboard, and rotate your key immediately if you suspect exposure.
- Treat the amount in the webhook as authoritative, and confirm it matches the order before you fulfil it.
Reporting a vulnerability
If you find a security problem, email [email protected] with the subject line "Security" and enough detail to reproduce it. We will acknowledge within 3 working days and keep you updated.
Please give us a reasonable chance to fix the issue before publishing it, and while testing: do not run denial-of-service attacks, do not access or modify data that is not yours, and do not use live customer payments as test cases. Use your own merchant account and your own money.
We do not currently run a paid bug bounty, and we will credit researchers who ask to be credited.
Contact
Questions about this page, or a request about your data, go to [email protected]. We aim to reply within 5 working days.
| Operator | [Legal entity name] |
|---|---|
| Registered address | [Registered address, city, state, PIN] |
| Grievance officer | [Name] · [Email] · [Phone] |
| Support email | [email protected] |