Sub-Merchant Payment Gateway: Run Multiple Websites Under One Merchant Account

6 min read ZurvaPay team
Sub-Merchant Payment Gateway: Run Multiple Websites Under One Merchant Account

If you manage payments for more than one website, a sub-merchant payment gateway setup saves you from repeating verification for every project. You verify one merchant account, then add each website or client as a sub-merchant under it.

This guide explains what sub-merchants are, who benefits, how they work on ZurvaPay, and how to keep many sites organised and secure.

What is a sub-merchant?

A sub-merchant is an additional business or website that operates under your verified merchant account. On ZurvaPay each sub-merchant has its own business name, website, API keys, transactions and pending payments. You, as the parent merchant, stay in control: you decide which sub-merchants exist and can switch a sub-merchant's API access on or off.

Who needs sub-merchant accounts

  • Web agencies and freelancers who build online stores for several clients and want each client to have its own payment keys.
  • Owners of multiple brands who run separate websites and want separate reporting for each.
  • Software and platform builders who deliver the same product to many customers.
  • Businesses with regional or product-line sites that should not share one set of keys.

How sub-merchants work on ZurvaPay

  1. Verify your own account. Open a merchant account, complete KYC and get approved.
  2. Add a sub-merchant. From your dashboard, enter the business name and the website of the new sub-merchant.
  3. Review. Our team reviews the sub-merchant against your already-verified KYC, so you do not upload documents again. A sub-merchant is pending until it is approved, and if one is rejected the reason is recorded against it.
  4. Go live. Once approved, the sub-merchant can have its own API keys and start accepting payments.

A new sub-merchant starts with the charge rate of your merchant account.

Setting up a sub-merchant

  • Use the client's real business name, because it is shown on the checkout.
  • Enter the exact website the sub-merchant will use. Callback URLs must be on the domain approved for it.
  • Wait for approval before you give the client keys. A sub-merchant that is not approved cannot process payments.

Separate API keys for every site

The biggest benefit is separation. Each sub-merchant gets its own public and secret key, so you never hand your parent account's secret key to a client. If a client's keys are exposed, you regenerate only that sub-merchant's keys and the rest of your sites are untouched.

Each site then integrates in the usual way, using its own public key:

curl -X POST "https://zurvapay.com/payment/initiate" \
  -F "public_key=SUB_MERCHANT_PUBLIC_KEY" \
  -F "identifier=SITEA-100245" \
  -F "currency=PKR" \
  -F "amount=1800" \
  -F "details=Order 100245" \
  -F "ipn_url=https://client-site.com/zurvapay/ipn.php" \
  -F "success_url=https://client-site.com/payment/success" \
  -F "cancel_url=https://client-site.com/payment/cancel" \
  -F "customer_name=John Doe" \
  -F "customer_email=john@example.com"

The signed IPN is verified with that sub-merchant's secret key, exactly as in the API documentation.

Managing and monitoring sub-merchants

  • Per-sub-merchant dashboard. Open any sub-merchant to see its activity.
  • Separate transactions. See the transactions of each site on its own, which makes reconciliation simple.
  • Separate pending payments. Track payments still waiting, per site.
  • API access switch. Turn a sub-merchant's API access off when a project ends or a client stops paying you, and back on when needed.
  • Key regeneration. Generate new keys for one site without affecting the others.

Example: an agency with three clients

An agency in Multan builds stores for three clients: a clothing shop, a tuition centre and a software reseller. The agency opens one merchant account and completes KYC once. It then adds three sub-merchants, each with the client's business name and website, and waits for approval.

  • Each client site is integrated with its own public and secret key.
  • The clothing shop's orders are numbered SHOP-, the tuition centre's EDU- and the reseller's SOFT-, so identifiers never collide and are easy to recognise.
  • At month end the agency opens each sub-merchant's transactions and pending payments and sends each client a clear statement.
  • When the tuition centre's contract ends, the agency switches off that sub-merchant's API access. The other two sites keep running.

This is the same account-level control, with client-level separation.

Best practices for agencies

  • Create one sub-merchant per client site, never one for several unrelated sites.
  • Prefix your order identifiers per site (for example SITEA-100245), keeping each under 20 characters and unique.
  • Store each client's keys in that client's configuration only, and never in a shared repository.
  • Write down who owns the sub-merchant and what happens at contract end: disable API access, then archive.
  • Agree with clients who contacts support when a payment is in question.
  • Test each new site with a small real payment, because ZurvaPay processes live payments only.

Security checklist

  • Keep every secret key on the server of the site it belongs to.
  • Verify both IPN signatures on every site before marking an order paid.
  • Answer the IPN with HTTP 200 and make the handler safe to run twice.
  • Use HTTPS for the website and every callback URL.
  • Regenerate keys immediately if a developer who had access leaves the project.
  • Review each sub-merchant's pending payments regularly and use the Payment Status API for anything stuck.

Sub-merchant or separate merchant account?

Use a sub-merchant when the sites belong to you or are managed by you under one verified relationship. Use a separate merchant account when a client is its own legal business that wants direct control of its account, balance and KYC. The client can register on its own through the merchant sign-up page.

Frequently asked questions

What is a sub-merchant on ZurvaPay?

An extra business or website that runs under your verified merchant account, with its own keys, transactions and pending payments.

Do I submit KYC again for each sub-merchant?

No. A sub-merchant is reviewed against the KYC of your parent merchant account.

Can I switch a sub-merchant off?

Yes. You can enable or disable the API access of each sub-merchant.

Is a sub-merchant live immediately?

No. Each sub-merchant is submitted for review and goes live after approval.

Can I use the same payment methods on every sub-merchant?

Sub-merchants use the same hosted checkout, so customers can pay with JazzCash, Easypaisa or Raast QR.

Add your first sub-merchant

Verify your merchant account, then add a sub-merchant from your dashboard. Learn more on the sub-merchant accounts page.

Related guides

Brand, bank and card network names are used only to describe payment methods and belong to their respective owners. ZurvaPay is an independent payment gateway and is not affiliated with or endorsed by them.

Start accepting payments with ZurvaPay

Open a merchant account, connect your website with one API and get notified the moment a customer pays.

Open a merchant account API documentation