I have a website with a user registration page in which they give their details including a bank account no for online transaction, if any user is registered with us we will generate a unique web link for them through which their clients will make an online payment.

this is the process. Now I want to know can I have an ecommerce page with multiple accounts?

Kindly help.

Dani AI

Generated

Short answer: yes — a single site can accept payments for many clients, but the implementation and legal/operational tradeoffs matter. Two common models are (A) “connected accounts” / marketplace flows where the gateway routes each payment to a seller’s account (you create a per-client connected/sub‑merchant and route money there), and (B) separate merchant accounts where you pick the correct merchant/MID per link and the gateway settles directly to that client’s bank. Examples of platform features that do this are Stripe Connect (destination/direct charges, application fees) and PayPal’s Commerce Platform. ()

If the goal is “one unique pay link for each client that deposits to that client’s bank,” use a marketplace/connected-account integration (so your server turns a /pay?client=ID request into a Checkout/payment session that sets the destination account). If instead you prefer each client to hold their own merchant account with the acquirer, generate links that route to the correct merchant account at checkout. For practical differences see Stripe’s Connect account types and destination‑charge flow. ()

Important cautions: if your platform ever holds pooled customer funds you may trigger money‑transmitter, KYC/AML, and extra underwriting requirements — the PayFac route shifts risk and compliance onto you. If you don’t want that, prefer “standard/express” connected accounts where the provider handles KYC. Also never store raw card or sensitive bank data unless you’re PCI‑compliant — tokenization/vaults and letting the gateway handle sensitive data are the safe choices. ()

Quick, practical checklist (start here): use the gateway’s sandbox; map client_id → connected_account_id in your DB; create a server-side Checkout that sets the destination; use tokenization/vaulting; implement webhooks for reconciliation, refunds and disputes; log everything and test chargebacks. Example pseudocode:

# server-side pseudocode
connected = lookup(client_id)
session = gateway.create_checkout({
  items, 
  payment_intent_data: { transfer_data: { destination: connected.gateway_account_id }, application_fee_amount: fee }
})
return session.url

Begin with one processor that supports marketplaces, validate onboarding and payouts with a few clients, then expand. This addresses ’s original flow and follows the clarifying points from , , and . ()

Recommended Answers

All 5 Replies

You can have it set up however you want, it's your application and you guys are writing it. Are you asking if there's a technical limitation or a limitation due to the payment processor you're using or what? Sorry, I'm confused by your question.

I am running a small company, we have more than 50 clients. For each client, who are registered with us we design a web page and a payment gateway to recieve funds from their sub clients.

To do this job I want an e-commerce account where I can divide my account into multiple accounts and assign to my clients for online transactions.
Hope I am clear this time. thank you

Do you mean multiple bank account per gateway? That's how i understand what you were saying? are you saying.. for example you want the client 1 to pay account 1 processed by the gateway, and client 2 pay to account 2 processed by the same gateway?

It is possible to have the differnet accounts for one web site , as specilay for ecomrace site

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.