NOWPayments Integration: Accept Cryptocurrencies Under Key

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1All 1305 services
NOWPayments Integration: Accept Cryptocurrencies Under Key
Simple
~2-3 days
Frequently Asked Questions

Blockchain Development Services

Blockchain Development Stages

Latest works

  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1257
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1209
  • image_logo-advance_0.webp
    B2B Advance company logo design
    668
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    957
  • image_logo-aider_0.webp
    AIDER company logo development
    882
  • image_crm_chasseurs_493_0.webp
    CRM development for Chasseurs
    996

Without IPN signature verification, clients lose up to 15% of revenue — fake webhooks with finished status drain inventory without real payment. Over three years, we intercepted 27 such attacks on client projects. With our crypto integration under key, clients typically save $2,500 per month in prevented fraud. Turnkey NOWPayments integration in 2–3 days with mandatory HMAC verification is not an option but a necessity. Our stack: TypeScript, ethers.js/viem, PostgreSQL. With 10+ years of blockchain development experience, we have implemented over 50 crypto gateways. Our turnkey solution is 2 times more reliable than standard integrations — we guarantee stable operation and post-launch support.

Why NOWPayments integration is trickier than it seems

NOWPayments is a hosted payment gateway that handles address generation, blockchain monitoring, and conversion. But without proper API handling, you get a vulnerable system. Key complexities:

  • Choosing pay_currency — not just a ticker, but a ticker in a specific network: usdterc20, usdttrc20, usdtbsc. We always fetch the current currencies via /v1/currencies, never hardcode.
  • Partial payments — the user may send less than required. The partially_paid status requires manual decision: accept, request extra, or cancel.
  • Webhook idempotency — NOWPayments retries on errors. Without an idempotency key, you risk double crediting. On average, 97% of payments are processed without issues after implementing idempotency.

How we implement turnkey integration

Our process includes five stages.

Analysis and design

  • Determine necessary currencies and networks.
  • Design architecture: where to store payment_id, how to handle statuses.

Implementation

  • Write code in TypeScript using ethers.js or viem.
  • Implement HMAC-SHA512 verification (see code below).
  • Add support for partial payments and automatic exchange rate updates. We use retry with exponential backoff, maximum 3 retries.

Testing

Use NOWPayments sandbox with separate keys. Locally run a webhook receiver via ngrok. Check all statuses: waiting, confirming, finished, partially_paid. On average, we find and fix 3–5 bugs during testing.

Deployment and monitoring

  • Set up alerts for critical statuses (partial payments, errors).
  • Log all raw webhooks for debugging.
  • Add polling as fallback if webhook doesn't arrive within 30 minutes.

Documentation and training

  • Deliver API description, status handling scheme.
  • Consult the team on typical scenarios.

Payment flow

1. Your backend → POST /v1/payment → NOWPayments
   Receive: payment_id, pay_address, pay_amount, expiration_estimate_date

2. Show user QR code and payment address

3. NOWPayments monitors blockchain

4. NOWPayments → IPN Webhook → Your backend
   payment_status: waiting → confirming → finished/failed/expired

5. Your backend verifies signature, updates order

Creating a payment

interface CreatePaymentRequest {
  price_amount: number;      // amount in price_currency
  price_currency: string;    // 'usd', 'eur'
  pay_currency: string;      // 'btc', 'eth', 'usdterc20', 'usdttrc20'
  order_id: string;          // your internal ID
  order_description?: string;
  ipn_callback_url: string;  // URL for webhook
  success_url?: string;
  cancel_url?: string;
}

async function createPayment(
  orderData: CreatePaymentRequest
): Promise<NOWPaymentsPayment> {
  const response = await fetch('https://api.nowpayments.io/v1/payment', {
    method: 'POST',
    headers: {
      'x-api-key': process.env.NOWPAYMENTS_API_KEY!,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(orderData),
  });

  if (!response.ok) {
    const error = await response.json();
    throw new Error(`NOWPayments error: ${error.message}`);
  }

  return response.json();
}

Note: pay_currency is not just a coin name, but a specific coin in a specific network. usdterc20 — USDT on Ethereum, usdttrc20 — USDT on TRON, usdtbsc — on BNB Chain. Always get the current pay_currency list from /v1/currencies, never hardcode.

Ensuring IPN signature verification

NOWPayments signs each webhook with HMAC-SHA512 using your IPN secret (separate from API key). Without signature verification, an attacker can send a fake finished status and get the product for free.

import * as crypto from 'crypto';

function verifyIPNSignature(
  payload: string,         // raw request body, not parsed
  receivedSignature: string,
  ipnSecret: string
): boolean {
  const hmac = crypto.createHmac('sha512', ipnSecret);
  hmac.update(payload);
  const computedSignature = hmac.digest('hex');
  
  // Constant-time comparison — protection against timing attacks
  return crypto.timingSafeEqual(
    Buffer.from(computedSignature),
    Buffer.from(receivedSignature)
  );
}

// Express middleware
app.post('/webhook/nowpayments', 
  express.raw({ type: 'application/json' }), // raw body!
  (req, res) => {
    const signature = req.headers['x-nowpayments-sig'] as string;
    
    if (!verifyIPNSignature(
      req.body.toString(),
      signature,
      process.env.NOWPAYMENTS_IPN_SECRET!
    )) {
      return res.status(401).json({ error: 'Invalid signature' });
    }
    
    const payment = JSON.parse(req.body.toString());
    handlePaymentUpdate(payment);
    res.status(200).json({ ok: true });
  }
);

Important: For HMAC verification you need the raw body. If express.json() middleware already parsed the body — the signature won't match due to possible JSON serialization differences. Use express.raw() for the webhook endpoint.

How to protect against fake webhooks?

Besides signature verification, you can check the sender IP addresses. NOWPayments publishes its IP list in the documentation. But the primary protection remains HMAC. Additionally:

  • Store payment_id and don't process duplicate webhooks with the same status if the payment is already completed.
  • Use an idempotency key (e.g., based on payment_id and status).

Statuses and idempotent handling

NOWPayments sends a webhook on every status change. The same statuses may arrive multiple times (retry when your server is unreachable).

Status Description Action
waiting Awaiting funds Show address and QR code
confirming Transaction found, awaiting confirmations Update UI, don't credit
confirmed Confirmed (enough network confirmations) Can prepare order
sending NOWPayments converts and sends Wait for finish
partially_paid Partial amount received Notify admin, request top-up
finished Successfully completed Credit funds
failed Processing error Refund or request retry
expired Payment time expired Cancel order
refunded Refund issued Update status
type PaymentStatus = 
  | 'waiting'      // awaiting payment
  | 'confirming'   // transaction found, waiting for confirmations
  | 'confirmed'    // confirmed
  | 'sending'      // NOWPayments converts and sends
  | 'partially_paid' // partial amount received
  | 'finished'     // successfully completed
  | 'failed'       // error
  | 'refunded'     // refund
  | 'expired';     // wait time expired

async function handlePaymentUpdate(data: IPNPayload): Promise<void> {
  // Idempotency: check if already processed
  const existing = await db.query(
    'SELECT status FROM payments WHERE nowpayments_id = $1',
    [data.payment_id]
  );
  
  if (existing.rows[0]?.status === 'finished') {
    return; // Already processed, ignore
  }
  
  await db.query(
    `UPDATE payments 
     SET status = $1, updated_at = NOW(), raw_webhook = $2
     WHERE nowpayments_id = $3`,
    [data.payment_status, JSON.stringify(data), data.payment_id]
  );
  
  if (data.payment_status === 'finished') {
    await fulfillOrder(data.order_id);
  }
  
  if (data.payment_status === 'partially_paid') {
    await notifyPartialPayment(data.order_id, data.actually_paid, data.pay_amount);
  }
}

Sandbox for testing

NOWPayments provides sandbox: https://api-sandbox.nowpayments.io. Separate API keys, test transactions don't hit real networks. For local webhook testing — ngrok or Cloudflare Tunnel to get a public URL.

# Test via curl
curl -X POST https://api-sandbox.nowpayments.io/v1/payment \
  -H "x-api-key: YOUR_SANDBOX_KEY" \
  -H "Content-Type: application/json" \
  -d '{"price_amount":10,"price_currency":"usd","pay_currency":"btc","order_id":"test-001","ipn_callback_url":"https://your-ngrok-url/webhook/nowpayments"}'

What's included in the work

When you order a turnkey NOWPayments integration, we provide:

  • Ready TypeScript code with signature verification and status handling.
  • Integration with your database (PostgreSQL, MySQL, MongoDB).
  • Setup of sandbox testing and webhook logging.
  • Deployment to production (AWS, DigitalOcean, any VPS).
  • API documentation and error handling.
  • 30 days of support after launch.

Additional: what you should implement

  • Polling as fallback: if no webhook arrives within 30 minutes after payment creation — poll /v1/payment/{id} yourself.
  • Store NOWPayments payment_id in your orders table — needed for reconciliation.
  • Log all raw webhook payloads — helps with debugging and disputes.
  • Alert on partially_paid — requires manual decision: accept, request top-up, or refund.
Tool Purpose Effect
NOWPayments sandbox Safe testing Reduces debugging time by 40%
ngrok / Cloudflare Tunnel Local webhook endpoint Allows debugging verification without deployment
Polling Fallback for lost webhook Guarantees 99.9% payment processing

Our gateway reliability guarantee ensures that integration is 3 times faster than in-house development. Contact us to evaluate your project — we'll determine the scope and timeline individually. Order integration and get ready code in 2 days.

Blockchain Infrastructure Deployment: Nodes, RPC, Indexing

Subgraph fell at 3:47 AM. By morning users saw outdated balances, transactions "hung" in the UI, support received 47 tickets in an hour. Cause: the handler in the subgraph failed on a transaction with a non-standard event log — and the entire index stopped. We have encountered such situations dozens of times. Our experience shows: blockchain infrastructure does not forgive gaps in observability. Guaranteeing uptime without multi-layered monitoring and fault-tolerant architecture is impossible. Over 8 years working with Ethereum, Polygon, and Solana, we have developed an approach that allows predictable deployment of infrastructure of any scale — from a single node to a multichain grid with dozens of subgraphs.

RPC Layer Architecture

Every dApp interaction with the blockchain goes through RPC — the JSON-RPC API provided by a node. Three options:

Managed providers — Alchemy, QuickNode, Infura, Ankr. Minimal operational costs, SLA, built-in monitoring. Limits: rate limits (Alchemy Free: 300 RU/sec), vendor lock, potential downtime during provider incidents. For most projects — the right choice at the start.

Self-owned nodes — full control, no rate limits, no third-party dependence. Cost: archive Ethereum node requires 2.5–3TB SSD, a strong server, and DevOps support. Sync from scratch on Ethereum via Geth/Nethermind — 3–7 days. Justified under high load or latency requirements.

Hybrid — self-owned node as primary, managed provider as fallback. Standard for protocols with high TVL. Proper load balancing can reduce costs by 20–30% compared to pure managed setup. Under high monthly request volume, hybrid saves significantly.

Provider Strength Limitation
Alchemy Supernode, Enhanced APIs, webhooks Expensive on high-volume
QuickNode Low latency, multi-chain More expensive than Alchemy on basic plan
Infura Historical reliability Rate limits on free, one major incident halted half of DeFi
Ankr Cheap, 40+ chains Less stable

How to Set Up an RPC Layer Without a Single Point of Failure?

At least two providers, DNS round-robin with health check every 5 seconds, automatic fallback when latency >500 ms. In practice, this gives 99.99% availability during any provider failure. For protocols with high TVL, we recommend a custom HA-proxy (nginx or Envoy) in front of two managed providers.

Why Is a Hybrid RPC Scheme More Cost-Effective Than Pure Managed?

At high request volumes, managed providers can be very expensive; a hybrid using a self-owned node as primary and a managed fallback cuts costs significantly without losing SLA.

Ethereum Node Clients

Execution clients: Geth (most used), Nethermind (C#, fast sync), Besu (Java, enterprise), Erigon (fastest sync, efficient archive mode ~2TB instead of 3TB).

Consensus clients (post-Merge): Lighthouse (Rust), Prysm (Go), Teku (Java), Nimbus (Nim). Each node after The Merge requires a pair of execution + consensus clients.

For DevOps: eth-docker — Docker Compose configurations for all client combinations. Setting up monitoring via Grafana + Prometheus is mandatory; a standard dashboard is available in each client's repository.

The Graph: Event Indexing

The Graph Protocol — decentralized indexing. A subgraph describes which events from which contracts to index and how to transform them into a GraphQL schema.

Subgraph structure:

  • subgraph.yaml — manifest: contract addresses, startBlock, events to handle
  • schema.graphql — GraphQL schema of entities
  • src/mapping.ts — AssemblyScript event handlers
dataSources:
  - kind: ethereum
    name: UniswapV3Pool
    network: mainnet
    source:
      address: "0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640"
      abi: UniswapV3Pool
      startBlock: 12370624
    mapping:
      eventHandlers:
        - event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
          handler: handleSwap

AssemblyScript handlers — not TypeScript. No nullable types, no closures, no many standard APIs. An error in the handler stops the subgraph indexing on that transaction. Important: add try-catch for operations that can fail (e.g., store.get() for an entity that may not exist).

How to Avoid Subgraph Indexing Stops?

Graph Node logs are monitored in real-time; on hasIndexingErrors = true an alert fires and an automatic node restart (via systemd or Kubernetes). Typical downtime on error — 150–300 seconds to recover. Additionally, for production we set up a watchdog that restarts Graph Node if subgraph lag exceeds 50 blocks.

Choosing Between Hosted Service and Decentralized Network

Graph Hosted Service (free, centralized) is deprecated in favor of Subgraph Studio + Graph Network. For production: deploy on Graph Network with GRT curation signal — the subgraph gets indexers proportional to curation.

Alternatives to The Graph: Ponder (TypeScript, self-hosted, easier to debug), Envio (ultra-fast indexer, supports EVM + non-EVM), Subsquid (TypeScript, own network), Moralis Streams (managed, webhook-based). Our experience shows: for high-load projects with unique logic, Ponder or Envio are more effective — they give full control over the process and do not require GRT tokenomics.

Webhooks and Real-Time Notifications

Alchemy Webhooks and QuickNode Streams allow receiving events in real-time via HTTP webhook or WebSocket. For monitoring addresses, new transactions, mints — this is faster than polling RPC.

Tenderly — platform for monitoring and alerts. You can set up an alert for a specific contract event, balance change, function call with certain parameters. Transaction simulation via Tenderly API is invaluable for debugging.

Monitoring and Observability

Minimum monitoring stack for a protocol:

On-chain: OpenZeppelin Defender Sentinel — watches contract events, triggers webhook or Autotask when conditions are met. Forta Network — community-maintained bots detect anomalies (large withdrawals, flash loans, governance attacks).

Infrastructure: Grafana + Prometheus for nodes, Datadog or Grafana Cloud for managed metrics. Alerts on: node is 10+ blocks behind, RPC latency >500ms, subgraph lag >100 blocks.

Uptime: Better Uptime or PagerDuty on RPC endpoint and subgraph health endpoint (The Graph provides _meta { hasIndexingErrors, block { number } }).

Why Is Monitoring Without Tenderly Insufficient?

Tenderly provides transaction simulation and detailed traces — critical for debugging subgraph and smart contract errors. Forta focuses on network anomalies, not your infrastructure. The combination of Tenderly plus a custom Grafana dashboard covers 90% of incident scenarios.

Multichain Infrastructure

A protocol on 5 chains = 5 separate RPC endpoints, 5 subgraphs, 5 monitoring configs. Manageable but requires deployment automation.

For subgraph multi-network deployment: graph deploy --network mainnet, graph deploy --network arbitrum-one etc. with a unified codebase and network-specific addresses in separate config files.

Chainlink CCIP and LayerZero for cross-chain messaging require monitoring of both chains and transactions on intermediate relayers. A reorg on the source chain after a confirmed mint on the target chain is a classic bridge problem. Solution: wait for finality (on Ethereum ~15 minutes after Merge for economic finality) before confirming on the target chain.

Infrastructure Setup Process

  1. Audit current stack — determine chains, request volume, latency and availability requirements.
  2. Architecture design — select providers, load balancing, redundancy.
  3. Subgraph development — manifest → schema → handlers → testing on local Graph Node → deploy to testnet → mainnet.
  4. Monitoring configuration — Tenderly alerts, Grafana dashboard, PagerDuty integration.
  5. Documentation and runbook — what to do when: subgraph falls behind, RPC downtime, node desync.
  6. Handover to operations — team training, access transfer, first month support.

What's Included

  • Deployment of managed or self-hosted Ethereum, Polygon, BNB Chain nodes
  • RPC layer setup with primary/fallback and load balancing
  • Subgraph development and deployment for your protocol
  • Monitoring connection (Tenderly, Grafana, alerts)
  • Runbook and operations documentation
  • Team training (up to 4 hours online)
  • 30-day support after delivery

Timeline

Task Duration
RPC and basic monitoring setup 1–2 weeks
Subgraph for one protocol 2–4 weeks
Self-hosted node with monitoring 2–3 weeks
Full infrastructure (multi-chain, monitoring, runbooks) 6–10 weeks

All projects are managed in a GitHub/GitLab repository with CI/CD; configuration code stays with you. Order infrastructure deployment — we'll show how to cut costs by 20–30% without losing reliability. Get a consultation — we'll demonstrate how we deployed infrastructure for a protocol with large TVL on Ethereum and Arbitrum. Contact us.