An amount-unit mistake can turn a small purchase into a payment request one hundred times larger than intended. Trust Gateway order requests use rupee amounts, while your application may sensibly store money as integer paise. Make that conversion explicit and treat the returned payable total as part of the order record.
- The order API accepts a positive INR amount with at most two decimal places.
- Do not include the currency symbol or display commas in the request value.
- Calculate the purchase total on your server.
- Preserve requested amount, payable amount and any matching adjustment separately.
Separate storage units from API units
One rupee contains one hundred paise. If your application stores an invoice for ₹499 as 49900 paise, convert it to 499.00 rupees before submitting it to this API. Sending 49900 as the amount represents ₹49,900, not ₹499. A number can pass syntactic validation and still be the wrong business amount.
Name fields by unit, such as totalPaise in your application and amountInr at the integration boundary. Do not rely on a developer remembering which service uses which unit. Keep display formatting, arithmetic and network payload formatting as separate steps.
Use plain decimal request values
The current parser accepts positive decimal values with zero, one or two fractional digits. Examples include 1, 1.5 and 499.00. A string such as ₹499 or 1,250.00 is presentation text and does not belong in the amount field. Values with more than two decimal places, negative amounts and zero are rejected.
| Value | Meaning or action |
|---|---|
| "1250.00" | A plain ₹1,250 request amount |
| "1,250.00" | Remove display formatting before constructing the request |
| "12.345" | Resolve the purchase's rounding rule before submitting |
| 49900 integer paise | Convert to 499.00 INR at the API boundary |
Parser acceptance is not a statement about your receiving account's transaction limits or provider eligibility. Check those separately. Also validate prices in your own application before the request reaches the gateway, rather than presenting raw gateway errors as the customer's normal purchase flow.
Calculate the total on your server
Your backend should load the product price, apply authorised discounts and determine the payable purchase total. A customer-controlled browser field should not decide the final amount for a fixed-price product. Store the result against your business order before calling the gateway so the confirmation can be checked against a known purchase.
Integer paise arithmetic avoids many decimal-representation surprises for ordinary additions and subtractions. For a non-negative integer total, an illustrative conversion is Math.floor(totalPaise / 100) + '.' + String(totalPaise % 100).padStart(2, '0'). Validate that the value is a safe integer first. This is only an amount conversion example, not a complete order-creation implementation.
Understand the returned amount fields
Trust Gateway order creation returns amount, requested_amount and matching_adjustment. The payable amount is the amount associated with the generated payment request. The requested amount records the original request, and the adjustment records any difference applied by the FamPay matching flow.
FamPay receipt alerts may omit the QR's order reference. The current order allocator can reserve a distinct payable amount for a receiving account when recent checkouts would collide. For example, an illustrative response might describe a requested ₹100.00 and payable ₹100.01. That is a conditional example, not a promise that every ₹100 request will be adjusted by one paisa.
Display the returned exact total clearly if an adjustment exists. Do not overwrite it with the basket's original total when drawing a QR or launching a UPI app. The hosted checkout shows the difference where applicable. An adjustment is a matching mechanism; it should not be described to customers as a provider fee without a separate factual basis.
Compare the correct values at confirmation
Store your business order reference, gateway order ID, requested total and expected payable total together. When payment is confirmed, verify the gateway data using the documented integration flow and compare the confirmed amount with the expected payable amount. A check against only the original basket total can incorrectly reject an intentionally adjusted request.
Exact amount alone is not sufficient evidence of payment. Another customer can pay the same value, and an old receipt may have the same total. Keep order identity, receiving identity and verified payment evidence in the decision. If an outcome remains ambiguous, preserve the attempt for review rather than choosing a purchase merely because its amount looks familiar.
Add focused amount tests before launch
- Try a whole-rupee value and a two-decimal value.
- Confirm that currency symbols and thousands separators do not enter API payloads.
- Check the rupee conversion from your internal paise total.
- Confirm the UI shows the returned payable amount, including a matching adjustment when present.
- Ensure invalid totals are rejected before the customer reaches payment approval.
Use the API documentation for the complete response contract, the routing guide for provider selection, and the reconciliation checklist when comparing successful orders with receiving-account records.