Compatibility alias: /api/payment/create-reqeust. Send the brand API key in the API-KEY header. The API never redirects the customer to a payment page.

curl -X POST 'https://api.nagorikpay.com/api/payment/create-request' \
  -H 'API-KEY: YOUR_BRAND_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "amount": "500",
    "payment_method": "bkash",
    "account_type": "personal",
    "cus_name": "Customer Name",
    "cus_phone": "01700000000",
    "webhook_url": "https://merchant.example.com/nagorikpay-webhook",
    "metadata": {"order_id": "ORDER-10025"}
    }'

{
  "status": "success",
  "payment_id": "NP202609130001",
  "payment_method": "bkash",
  "account_type": "personal",
  "payment_number": "017XXXXXXXX",
  "amount": "500.00",
  "charge": "10.00",
  "total_amount": "510.00",
  "pay_amount": "510.00",
  "breakdown": {
    "amount": "500.00",
    "charge": "10.00",
    "total_payable": "510.00"
  },
  "currency": "BDT",
  "expires_at": "2026-09-13 13:00:00"
}

curl -X POST 'https://api.nagorikpay.com/api/payment-submit-transaction' \
  -H 'API-KEY: YOUR_BRAND_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "payment_id": "NP202609130001",
    "transaction_id": "ABC123XYZ"
    }'

Response fields can include payment_id, transaction_id, amount, pay_amount, charge, status, message and the original verification details.

Every submit response — paid, pending, failed or expired — carries amount, charge, total_amount and pay_amount together, so the create response and the submit response never disagree about the money.

amount is always the merchant-requested amount, never the payable one — show pay_amount to the customer. When an amount mismatch is detected, expected_amount (what the request needs) and received_amount (what the provider SMS says arrived) are returned as well, so the difference can be shown without any guessing.

If webhook_url was supplied, the same payment status notifications are delivered to it. Existing form fields remain unchanged for compatibility. New headers are added:

Content-Type: application/x-www-form-urlencoded
X-NagorikPay-Timestamp: 1789290000
X-NagorikPay-Event: auto-completed
X-NagorikPay-Signature: sha256=HEX_SIGNATURE

The signing key is your brand's Webhook Secret if you have generated one (merchant panel → Brands → edit brand → Webhook Secret), and your brand API key if you have not. The Webhook Secret is the recommended setup: it is a separate value, so a leaked API key can no longer be used to forge webhooks.

timestamp + "." + raw_form_body
HMAC-SHA256(message, webhook_secret_or_api_key)

Webhook delivery attempts, response code, response body and payload are recorded in the merchant Webhook Logs page.

Read the raw request body — not a re-encoded array, and never a parsed-then-rebuilt string, since the signature covers the exact bytes that were sent. Reject requests with a timestamp older than five minutes, then compare the signature with a constant-time comparison.

$timestamp = $_SERVER['HTTP_X_NAGORIKPAY_TIMESTAMP'] ?? '';
$given = $_SERVER['HTTP_X_NAGORIKPAY_SIGNATURE'] ?? '';
$rawBody = file_get_contents('php://input');
$expected = 'sha256=' . hash_hmac(
    'sha256',
    $timestamp . '.' . $rawBody,
    'YOUR_WEBHOOK_SECRET_OR_API_KEY'
);

// A signature is always sent — a missing one means the request is not ours.
if ($given === '' || abs(time() - (int) $timestamp) > 300 || !hash_equals($expected, $given)) {
    http_response_code(401);
    exit('Invalid signature');
}

parse_str($rawBody, $payload);
// Process payment only after the signature check.