Society Online Payment Security Checklist

Society online payment security checklist

Secure society online payment requires more than an HTTPS checkout page. The app must calculate dues server-side, isolate every society at the database layer, keep bank and KYC data out of client storage, verify raw webhook signatures, reject duplicate events, and preserve an audit trail from onboarding through payment posting.

Protect the amount and bill identity

The browser should send the bill it wants to pay, not a trusted amount. Plinth's payment-intent RPC re-reads the outstanding balance and binds the intent to the society, flat, and invoice. This prevents a modified browser request from crediting ₹6,000 after paying ₹60.

Keep payment credentials at the gateway

Cashfree hosted checkout collects UPI, card, and netbanking credentials. Plinth receives a payment session identifier, not the resident's card or UPI PIN. The browser cannot settle its own intent.

Verify callbacks before changing money state

Cashfree signs webhooks over the timestamp plus the exact raw request body. Re-serialising JSON before verification can change decimal formatting and invalidate the security check. Plinth verifies first, then parses, and uses an idempotent database settlement function.

Vendor-status callbacks use the same pattern. Stale or duplicate event times are acknowledged without repeating the database or audit update.

Minimise bank and KYC data

Plinth keeps only the account-holder name, IFSC, masked last four digits, and operational provider status. Full account numbers, PAN values, document values, and VPA values are redacted from stored provider responses. Uploaded PAN and GST files go directly to Cashfree.

Enforce tenant and role boundaries

Row Level Security lets an admin read only a payment account for a society they administer. Residents cannot read the onboarding record. No client role can insert or update it, and the gateway-switch RPC is service-only.

Audit irreversible state changes

The append-only audit log records vendor submission, document upload, provider status transition, gateway activation or deactivation, and payment settlement. Duplicate provider events should not create duplicate audit entries.

Frequently asked questions

Is a signed webhook enough by itself? It proves the provider sent the event. You still need amount validation, tenant checks, idempotency, and database constraints.

Why keep unknown provider states offline? Because a new state may mean review or restriction. Assuming “pending” can hide a required action.

Can support staff read KYC documents from Plinth? No. M2 forwards supported files without retaining them.

See resident payment steps and admin Cashfree setup.