When a user pays online, the browser is the least trustworthy participant in the conversation. It can send any amount, and it can visit your "payment successful" URL without paying anything. In BasaFinder, tenants pay rent for an approved rental request through the ShurjoPay gateway, in BDT. This post describes how the API keeps the amount and the payment status under the server's control.

The flow in five steps

The tenant starts checkout for a rental request. The endpoint requires a signed-in tenant.
The server loads the data itself. It fetches the request and the listing, and rejects the call if the request is not approved, the listing does not exist, or the request belongs to a different tenant.
The server creates a payment record with the status Pending. The amount comes from the listing's rent.
The server creates the ShurjoPay checkout, using the payment record's id as the order id and BDT as the currency, and returns the checkout URL. The gateway's order id is stored on the payment record.
After the gateway redirects the tenant back, the client calls a verify endpoint with the order id. The server asks ShurjoPay for the real result, updates the payment, and marks the rental request as paid if the payment succeeded.

The amount never comes from the client

The request body may include an amount, but the server does not use it. Both the payment record and the gateway call take the price from the listing that the server just loaded:

const listing = await RentalHouse.findById(payload.listingId);
if (!listing) throw new AppError(404, 'Rental listing not found');

const payment = await Payment.create({
  tenantEmail: user.email,
  listingId: payload.listingId,
  requestId: payload.requestId,
  amount: listing.rentAmount,   // not payload.amount
  status: 'Pending',
});

Because of this, editing the request in the browser's network tab cannot change what the tenant is charged.

The status comes from verification, not from the redirect

Landing on the client's "payment result" page proves nothing, since anyone can type that URL. So that page only reads the order_id from the URL and asks the server to verify it. The server queries the gateway and maps the bank's answer to a status:

status:
  bank_status == 'Success' ? 'Paid'
  : bank_status == 'Failed' ? 'Pending'
  : bank_status == 'Cancel' ? 'Cancelled'
  : ''

if (payment.status === 'Paid') {
  await RentalRequest.findByIdAndUpdate(payment.requestId, { paymentStatus: 'paid' });
}

Two details are worth noting. A failed payment goes back to Pending rather than to a terminal state. And since the status is always written from the gateway's answer, calling the verify endpoint twice re-reads the result and writes the same status, which makes a page refresh harmless. In this checkout flow, a request becomes paid only when the gateway says the payment succeeded.

Who can see the money

Reads are scoped by role. A tenant sees their own payments, a landlord sees payments for their own listings, and an admin sees all of them along with a total-revenue endpoint. The listing and payment collections are linked by id, so the landlord view is a query over the landlord's listing ids.

What I would tighten

Check ownership in the verify endpoint. It takes an order id from the query string and any signed-in role may call it. It only reads the gateway's answer, so the risk is small, but it should also confirm the order belongs to the caller.
Do not depend on the browser coming back. Verification is triggered by the client after the redirect. If the tenant closes the tab first, the payment stays Pending until someone verifies it. A server-to-server notification from the gateway, where the gateway offers one, would remove that dependence.
Keep the gateway credentials out of the code. The ShurjoPay endpoint, username, password and return URL are read from configuration, not written into the source.

The rule I take from this flow: the server owns two things in any payment flow, the amount and the final status. Everything the browser sends is a request, and everything the browser shows is a view.

Taking Payment Amounts from the Server: BasaFinder and ShurjoPay