The signature computed with the sample credential matches the one in this documentation.
All field values are sent as strings, and amounts are not sent as a numeric type.
Collection order creation has been tested in both url and json modes (whichever you use) and on both the fps and bank_transfer channels.
The payment screen displays payable_amount, not the original amount.
Payout order creation has been tested with all three FPS account formats (whichever you use) and with bank transfer.
Callback endpoint: verifies signatures correctly, discards Callbacks whose signature does not match, handles duplicate notifications idempotently, and responds ok within 10 seconds.
Callbacks are matched to orders by order_no, and collections can be distinguished from payouts.
A periodic order query mechanism is in place to handle missing Callbacks and late_credited orders.
Order creation timeouts and internal_error are confirmed by querying with the merchant order number, instead of being treated as failures right away.
Your program determines results by code and does not rely on the message text.
The production credentials, domain, and IP whitelist have been requested separately, and the secret key is stored only on the server side.
Your server time is accurate (NTP time synchronization is recommended), and every request's timestamp is the time it is sent.
Every order creation request includes callback_url. The URL is a valid http or https URL (both are accepted), the domain resolves on the public internet to public IP addresses only, it does not redirect (3xx), and your server responds with HTTP 2xx.
A successful collection is credited with received_amount (or settlement_amount). If it differs from the expected amount, it goes to manual review instead of being credited automatically.
An order already in a final status is never rolled back by a later Callback with a different status; when in doubt, the order query result prevails.
