BharatPe Merchant API vs VyaparGateway: Developer Comparison

“BharatPe Merchant API” is a popular search because developers want to turn a BharatPe-connected merchant workflow into an online checkout. The comparison needs one clarification upfront: BharatPe’s public merchant product and VyaparGateway’s developer API operate at different layers.

As reviewed on 28 July 2026, BharatPe’s public website describes interoperable merchant QR acceptance, the BharatPe for Business experience, sound boxes, POS devices, and related financial products. We did not find a public, self-service ecommerce API reference on that site for creating an order, returning a dynamic QR, and subscribing to payment webhooks.

That absence is not proof that no partner API exists. Payment companies commonly provide private documentation after commercial and compliance review. Ask BharatPe for the current official route if you need a direct enterprise integration.

Two different product layers

BharatPe merchant product

For a merchant, BharatPe focuses on accepting and managing payments. Its public site advertises:

• an interoperable BharatPe QR;
• acceptance from multiple UPI apps;
• BharatPe for Business;
• real-time voice alerts through a sound box;
• card acceptance products;
• merchant credit and other financial services.

This can be ideal for a physical counter. The merchant displays a QR, receives money, and uses the merchant app or device for operational confirmation.

VyaparGateway developer layer

VyaparGateway focuses on the application boundary:

• create an order with a merchant-owned idempotency reference;
• generate an amount- and order-specific UPI payload;
• return QR and intent artifacts;
• connect a supported merchant provider account;
• check an order from a server;
• send a signed payment callback;
• give the merchant software one integration surface.

Your store / SaaS / ERP
          │
          ▼
VyaparGateway order + verification API
          │
          ▼
Supported connected merchant provider
          │
          ▼
UPI / bank account settlement

VyaparGateway is not a bank and should not be described as changing the underlying payment-provider relationship. It supplies checkout orchestration around an eligible connected merchant setup.

Developer capability comparison

The table compares publicly verifiable product surfaces, not unverified private capabilities:

Developer concern	BharatPe public merchant surface	VyaparGateway developer surface
Primary audience	Merchants accepting payments	Developers and merchants automating online orders
Public merchant QR	Yes	Generated from the connected merchant context
Public self-service ecommerce API docs	Not located in the reviewed public BharatPe pages	Public overview; exact authenticated reference in dashboard
Order idempotency	Not documented publicly for a merchant API	client_txn_id reuses an existing order within the tenant
Dynamic amount QR	Ask BharatPe for current partner capability	Returned by create-order workflow
Server status check	Not documented publicly for a merchant API	POST /api/v1/check_order_status
Signed merchant webhook	Not documented publicly for a merchant API	HMAC SHA-256 integration pattern
Multi-provider abstraction	BharatPe-specific merchant product	Designed around supported provider connections
Settlement	Governed by BharatPe merchant product and rail	Governed by the connected provider/merchant relationship
Commercial model	Obtain current BharatPe terms	Flat software plan advertised from ₹300/month

Treat “not publicly documented” as exactly that. Do not convert it into a claim that BharatPe lacks an internal feature.

The practical difference

An offline merchant can recognise a paid counter transaction through an app notification or sound box. An ecommerce application needs machine-verifiable answers:

1. Which internal order was paid?
2. Was the amount exactly ₹1,249.00?
3. Is the event authentic?
4. Has this event already been processed?
5. Can the server recover if the webhook was delayed?
6. Can fulfilment run once even if the provider retries?

That is the gap an API and webhook layer is intended to close.

VyaparGateway integration example

Keep the API key on your backend. Create an order with a stable merchant reference:

curl --request POST \
  --url https://vyapargateway.com/api/v1/create_order \
  --header 'Content-Type: application/json' \
  --header 'X-API-Key: YOUR_SERVER_SIDE_KEY' \
  --data '{
    "client_txn_id": "ORDER_2026_1042",
    "amount": 1249.00,
    "p_info": "Cotton kurta order 1042",
    "customer_name": "Meera Shah",
    "customer_email": "[email protected]",
    "customer_mobile": "9876543210",
    "redirect_url": "https://shop.example/orders/1042",
    "callback_url": "https://shop.example/webhooks/vyapargateway"
  }'

The deployed authenticated reference is authoritative for response fields. Conceptually the application receives:

{
  "status": true,
  "data": {
    "order_id": "provider-independent-order-reference",
    "client_txn_id": "ORDER_2026_1042",
    "amount": "1249.00",
    "status": "pending",
    "upi_string": "upi://pay?...",
    "qr_code": "data:image/png;base64,...",
    "expires_at": "2026-07-28T18:30:00Z"
  }
}

Render only public checkout artifacts in the browser. Do not expose X-API-Key, connected-provider credentials, or the webhook secret.

Check an unresolved order

If a callback was delayed, your server can reconcile by order ID or client_txn_id:

curl --request POST \
  --url https://vyapargateway.com/api/v1/check_order_status \
  --header 'Content-Type: application/json' \
  --header 'X-API-Key: YOUR_SERVER_SIDE_KEY' \
  --data '{
    "client_txn_id": "ORDER_2026_1042"
  }'

Periodic status checks should be bounded. Checking every second forever wastes resources and can amplify an outage. A common strategy is:

0–30 seconds: browser asks your backend every 3–5 seconds
30–120 seconds: back off to every 10 seconds
after expiry: stop browser-side status checks
scheduled job: reconcile old pending orders server-to-server

Verify the webhook

import crypto from "node:crypto";

function validSignature(
  rawBody: Buffer,
  signatureHex: string,
  secret: string,
) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)
    .digest();
  const received = Buffer.from(signatureHex, "hex");

  return (
    received.length === expected.length &&
    crypto.timingSafeEqual(received, expected)
  );
}

After signature verification, compare the event to your database record:

if (event.client_txn_id !== order.clientTxnId) throw new Error("reference mismatch");
if (event.currency !== "INR") throw new Error("currency mismatch");
if (event.amount !== order.amount) throw new Error("amount mismatch");
if (processedEventIds.has(event.id)) return { ok: true };

await markPaidAndEnqueueFulfilment(order, event);

Use decimal or integer-paise arithmetic in the real implementation. JavaScript floating-point equality is shown only as pseudocode above.

Security and operating model

Merchant eligibility

Connect only an account that the provider permits for business acceptance. Do not:

• use a personal VPA to imitate a merchant checkout;
• bypass provider onboarding or risk controls;
• collect another merchant’s credentials without authority;
• attempt unauthorized access methods;
• promise that every merchant account supports the same API functionality.

Provider connectivity is a contractual as well as technical concern. Confirm current support in the VyaparGateway dashboard and with the underlying provider.

Separate trust boundaries

There are three independent identities:

Customer identity       → handled by checkout/store policy
Merchant API identity   → X-API-Key or current server credential
Webhook sender identity → HMAC signature over raw bytes

An API key authenticates your server to create or query orders. It does not authenticate an inbound webhook. A webhook secret authenticates a callback. It should not be reused as the API key.

Failure modes

Design for:

• provider account disconnected;
• VPA missing or changed;
• two simultaneous orders with the same amount;
• late payment after expiry;
• duplicate webhook;
• webhook before the checkout page starts its status refresh;
• customer paying a different amount;
• one provider unavailable while another remains connected.

A multi-provider layer can reduce integration duplication, but it cannot remove underlying bank or provider outages. Your UI should show a neutral pending state and avoid promising a result before verification.

Which should you choose?

Choose the BharatPe merchant product directly when:

• your main use case is counter or offline QR acceptance;
• staff can operate through the merchant app or device;
• you do not need a public ecommerce order API;
• BharatPe’s current merchant terms fit your business.

Ask BharatPe about direct partner access when:

• you have enterprise volume and a formal integration programme;
• you need capabilities only BharatPe can contractually expose;
• you can complete the required security, compliance, and operational review.

Use VyaparGateway’s developer layer when:

• your website, SaaS, WooCommerce store, or ERP needs order-specific UPI;
• signed callbacks must drive fulfilment;
• you want one order/status model across supported connected providers;
• flat software pricing is preferable to a percentage platform fee;
• you accept the underlying provider’s onboarding and usage requirements.

The honest comparison is not “Which company has UPI?” Both product families participate in the merchant payment ecosystem. The comparison is whether you need a merchant acceptance product, a reliable developer API layer, or a contracted combination of both.