Poll without flooding the API

Poll from your server every three seconds: at most 20 status reads per minute for one active payment. Wait for each response before scheduling the next request. Three concurrent payments can consume the full 60-read per-key allowance; reserve capacity for other reads.

On HTTP 429, honor Retry-After and add a little jitter. Stop on paid, failed, cancelled or expired; set a total timeout. Pause browser-triggered polling when the page is hidden or the checkout closes. Never recreate a payment to recover from a read error.

Your browser calls your application’s own order-status route. That route checks the customer session and resolves the payment ID from the authorized order, then calls KH Payment. Never expose the API key or allow customers to query arbitrary payment IDs through a shared server key.

Private Node SDK helper

import { createClient, waitForPayment } from 'khpayment-sdk';
const client = createClient({
  baseUrl: process.env.KHPAYMENT_BASE_URL,
  apiKey: process.env.KHPAYMENT_API_KEY,
});
const payment = await waitForPayment(client, paymentId, {
  intervalMs: 3000, timeoutMs: 600000, signal,
});
// Validate environment and verification before fulfillment.
// Simulated results cannot fulfill live orders.

The helper uses sequential reads, Retry-After backoff, cancellation and a deadline. It never retries payment creation. Existing status reads can trigger a bounded provider check; autonomous tracking and signed webhooks are the next backend milestone.