A SaaS platform may give each customer a workspace while using Trust Gateway to create UPI checkouts. The platform then has two identity questions: which workspace created the order, and which customer should receive the service after payment? Solve both in your database before generating any checkout URL.
Bind an order to a tenant at creation
Authenticate the SaaS user, resolve their tenant from your session and check their permission to create a purchase. Calculate the price on the server. Save tenant ID, local purchase ID, buyer ID, product snapshot and selected receiving route together. Never accept tenant ID, price or receiver choice solely from an untrusted browser request.
Create the gateway order on your server and save the returned order reference, payable amount and expiry under that tenant. The browser only needs the hosted checkout URL. The first API order guide describes the basic server-side flow.
Keep credentials at the server boundary
Store API keys as secrets on the backend and grant access only to the payment service that needs them. Do not put a merchant key in a React environment variable, mobile build, HTML page or webhook URL. If your SaaS supports a distinct gateway account per tenant, keep an explicit tenant-to-credential mapping; never let one tenant submit the credential identifier of another. Rotate compromised keys and audit which service used them. See the key management guide.
Authorize every status lookup
A gateway order ID may appear in a checkout URL or support message. Treat it as an identifier, not an access token. When a user asks to view or verify a purchase, first load the local record under their authenticated tenant and confirm their access. Then call the authenticated status endpoint from your server with the credential associated with that record.
Require paid status, expected gateway order ID and exact payable amount before changing the local purchase. Keep a unique constraint on gateway order ID and make fulfilment idempotent. Repeated status requests, webhooks and background checks should converge on the same purchase rather than issue another licence or credit.
Route notifications through saved ownership
If you use webhook notifications, verify them as documented, look up the saved order and route work to its tenant. Do not use an unverified tenant label inside a callback to select which account receives value. When the callback cannot be matched, hold it for review instead of guessing. An authenticated status check remains the recovery path when a notification is delayed or missed. Read the webhook recovery guide for duplicate handling.
Test cross-tenant access
Create two test tenants with separate purchases. Confirm tenant A cannot read tenant B's order by changing a URL or API parameter, cannot trigger B's status check and cannot receive B's fulfilment. Test two same-amount orders, repeated callbacks and a tenant whose receiver is unavailable. Log local purchase and tenant identifiers for debugging while excluding API keys and full payment credentials.
This architecture belongs to your SaaS application. Trust Gateway provides payment orders and status; it does not automatically enforce your product's tenant membership or entitlements.