Credentials are read at runtime from configuration or the database, not from code.
The secret key does not appear in the repository, in the browser, or in logs.
Idempotency-Key is sent on every creation, derived from the order's content, not only its id.
The payment id is stored locally at creation; GET /payments?external_reference= is the recovery path, not the primary one, and it can return several matches.
The creation response is verified: total, sales_tax_amount and service_fee_amount are as expected.
The webhook endpoint verifies the HMAC signature over the raw body, with constant-time comparison.
The webhook responds 200 fast and processes asynchronously and idempotently by event id.
The webhook endpoint is registered in the portal, in the environment matching the key.
Landing on success_url does not mark the order as paid.
A direct-lookup fallback exists for orders left pending.
HTTP calls have timeouts (~30 s), with retries only on creation and the same idempotency key.
Reversal logic tries void first and falls back to refund when the transaction is already settled.
At least one real minimum-amount payment was tested end to end before going live.
Mobile only: the secret key is not in the app binary, the checkout opens in the system browser,
return URLs are https Universal/App Links, and the app confirms via its own backend.
