A checkout amount should reach the payment platform from the merchant's server after the server has resolved the product being purchased. Letting a browser supply the payable amount gives a buyer control over a value the merchant later uses to release goods.
The StableIn local merchant example makes this boundary unusually easy to inspect. Its purchase endpoint accepts one field, sku, and rejects additional fields. A server catalog maps that identifier to the token and raw amount. The payment platform then validates its own merchant and network context. These are separate checks, owned by different services.
Resolve the product before creating the payment
The example catalog contains a test-token product with raw amount 100000000 and a native-asset product with raw amount 1000000000000000. The browser selects the product. The merchant server supplies the configured chain, gateway, token address and amount when it creates the platform order.
This distinction matters when adapting the example. The general payment API accepts an amount from an authenticated merchant integration. It does not independently know the merchant's product catalog. A developer who forwards a browser amount through that integration would remove the catalog protection even though the payment API still validates its request schema.
Keep the catalog decision in the trusted merchant service. If quantity, discounts or tax rules are added, that service needs to calculate the resulting amount and retain the inputs used. Those capabilities would be extensions to the small example. An order should remain explainable after the catalog changes, using the price decision saved when the buyer started checkout.
Keep units attached to their asset
A displayed value of 100 for a six-decimal token corresponds to the integer 100000000. The ERC-20 specification describes decimals as the conversion used for user representation and makes the metadata method optional. Token symbols alone therefore cannot establish either identity or a trusted precision rule.
Use an explicit supported-asset record keyed by network and token address. Store the raw integer as a decimal string at the API boundary and use integer arithmetic for calculations. If a human-entered price has more fractional digits than the supported precision, return a validation error instead of silently changing the payable amount. Confirm any rounding rule for fees separately from price parsing.
StableIn's order service calculates the fee with integer multiplication and division by 10,000, then subtracts it from the gross amount. The demonstration's fee configuration is illustrative. It is not a commercial price promise, and the example does not establish compatibility with arbitrary tokens.
| Order field | Trusted source | Review condition |
|---|---|---|
| Product identifier | Buyer selection checked against catalog | Reject unknown products and extra price fields |
| Raw amount | Merchant catalog or pricing service | Compare exact decimal strings |
| Chain and gateway | Merchant deployment configuration | Match the configured merchant environment |
| Token address | Supported asset configuration | Reject symbol-only asset selection |
| Deadline | Saved platform order | Repeating a request must preserve its original expiry |
| Returned order | Payment platform response | Match merchant order, token, network and amount |
Check the returned quote before using it
The merchant example compares the returned platform order with its local order. It checks the merchant reference, chain, gateway and token, then the amount and required confirmation policy. Once a platform ID exists, a different ID is also rejected. This catches a response that belongs to another purchase before the shop saves its checkout URL.
At platform level, creation requires an active merchant and the merchant's configured chain. The token must be supported by the deployment manifest. The service checks the current merchant owner, payout address and signer against stored configuration before saving the payment intent.
The signing worker repeats material checks. It rejects an expired deadline, reconstructs the intent and checks its digest, then confirms that the current merchant configuration still matches. That second check covers the interval between order creation and signing, when a configuration change can invalidate a previously prepared order.
Review precision and expiry together
The worksheet includes a one-unit amount, an extra fractional digit, an unsupported token and a changed network. It also asks reviewers to replay the same purchase key after expiry. StableIn's existing replay path returns the stored resource without resetting the deadline. A fresh purchase should be an explicit new operation with its own identity.
Record expected errors and compare saved values before and after each case. A formatted UI screenshot alone cannot demonstrate that the integer amount stayed unchanged. The worksheet cases are unrun review exercises, separate from historical local product evidence.
Download the order validation and precision matrix.
StableIn Payments demonstrates this flow with a local test chain and test assets. A project review should bring the existing order interface, supported network and asset addresses, and the rule that authorizes delivery.
