处理多个第三方电子商务交易
我目前正计划开发一个网络应用程序，允许第三方在其上列出和销售自己的产品。
虽然我有开发电子商务解决方案的经验，但我个人不希望自己与实际的支付系统有任何关系（法律上而不是技术上），因此任何交易都在买方和卖方之间进行，而我自己只是第三者。
我对使用 Paypal 犹豫不决，因为我想显得专业，而且我不信任或不喜欢他们。我也不想使用任何银行或商家帐户，因为理想情况下我需要为每个客户提供一个帐户（而不是拥有一个集中帐户），这会导致向卖家收取过高的费用。
这样做的最佳方法是什么？如果绝对必要的话，我可能愿意接受交易中的某些部分（最好是低风险的）。我希望尽可能减少费用和管理费用。
这最初将是一个位于英国的网站，但有可能在全球范围内访问。它也将用（可能）PHP 开发，但这应该与该问题无关。
感谢您的任何见解！
I am currently planning to develop a web-app which will allow a 3rd party to list and sell their own products on it.
While I have experience with developing e-commerce solutions I personally do not want anything to do with the actual payment system myself (legally rather than technically) so that any transactions are between the buyer and the seller, with myself just as a 3rd party.
I am hesitant to use Paypal as I want to seem professional, plus I don't trust or like them. I also do not want to use any banking or merchant account as ideally I would need one for each customer (rather than having a centralized one) which would lead to excessive fees placed on the seller.
What is the best way of doing this? I possibly would be willing to accept some part in the transaction (preferrably low-risk) if absolutely necessary. I am looking to minimize fees and overhead as much as possible.
This will be a UK based site initially, but with potential worldwide access. It will also be developed in (probably) PHP but that should be tangential to the issue.
Thanks for any insight!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们在德国运营 www.hitmeister.de 一个大型市场。您的计划听起来和我们所做的一样，非常准确……
在我们的系统上，合同是在买方和卖方之间签订的。不过，所有资金都通过我们的账户运行，使我们成为交易的中介。客户可以通过直接借记卡、信用卡、PayPal等方式付款。卖家只能通过银行转账的方式收到款项。我们将代管资金，直至交易完成。
为 Paypal 和直接借记进行此设置并不是一个大问题。信用卡运营商通常不喜欢这些安排，因为您正在变成（半）收单方。不过，如果你和他们交谈，他们就会这么做。
希望有帮助
we run www.hitmeister.de a large marketplace in Germany. What you are planning sounds like what we do, quite exactly...
On our system, the contract is between the buyer and the seller. All funds run through our accounts though, making us an intermediary in the transaction. The client can pay through direct debit, credit cards, paypal etc. The seller can only receive the money via bank transfer. We hold the money in escrow until the transaction is complete.
Getting this setup for Paypal and direct debit was not a big problem. Credit card operators generally do not like these arrangements, as you are turning into a (semi-)acquirer. They will do it though, if you talk to them.
Hope that helps
http://www.wisegeek。 com/what-are-the- different-methods-for-handling-ecommerce-transactions.htm
http://www.developer-resource.com/ecommerce-benefits.htm
查看这两个链接。我认为这肯定会对您有所帮助
http://www.wisegeek.com/what-are-the-different-methods-for-handling-ecommerce-transactions.htm
http://www.developer-resource.com/ecommerce-benefits.htm
view that both links.I think this will help you surely
您的业务是让商家获得客户付款（或帮助他们获得付款），还是吸引客户并处理和传输相关信息？我同意前者是一个巨大的法律和企业责任混乱。谁愿意接听那些愤怒的人打来的电话或电子邮件，询问他们的购买和付款情况？最好从事后者吸引客户和推送信息的业务。
如果只是后者，则向每个商家索取用于建立服务的表单上的 URL 模板或结账链接。我所说的 URL 模板是指包含可变组件的 URL，例如交易金额、客户 ID 等。当客户需要向商家付款时，使用此模板将客户重定向到适当的系统。这样，小商家可以使用 paypal，但也可以支持拥有自己系统或 paypal 以外的系统的较大商家。
无论您为每个商家做什么，都会向他们收取费用。
如果它可以在商业方面以这种方式工作，那么主要的技术问题是分析主要的支付服务输入要求（paypal、google payment，也许是一两个商家抄送系统），以了解您的网站需要什么来满足其网站的需求（这可能是URL 模板（或者可能更多）并创建相关向导，以便商家轻松设置。优点是，如果您做得正确，您还将支持大多数内部商家系统，因为他们需要收集相同的基本信息。
Is your business to get merchants paid by their customers (or help them get paid) or is it to attract customers to them and process and transfer related information? I agree the former is a big legal and CR mess. Who wants to handle calls or emails from random irate people about their purchases and payments? Better to be in the latter business of attracting customers and pushing information.
If it is just the latter, then ask each merchant for a URL template or checkout link on the form that they use to establish service. By URL template I mean a URL with variable components like the amount of the transaction, customer id, etc... Use this template to redirect the customer to the appropriate system when it is time for them to pay the merchant. This way the small merchants can use paypal but the bigger merchants with their own systems or, something other than paypal, can also be supported.
Bill each merchant for whatever it is you do for them.
If it can work this way business-wise then the main technical problems are analysing the major payment services input requirements (paypal, google payments, maybe a merchant cc system or two) to understand what your site needs to feed their site (this might be URL templating or it might be more) and creating related wizards for easy setup by the merchants. The advantage is that if you do this right you will also support most in house merchant systems because they will need to collect that same basic information.