I'm building a marketplace application:
The customer pays the seller on the marketplace
The marketplace takes a cut of the payment
I would have a payment processing system with the following features
The cut and the 100%-cut are sent directly to the marketplace and seller accounts (ie, I don't want to have 100% on the marketplace account and then to forward the 100%-cut to the seller)
I would love to have a UI as much integrated with the marketplace website as possible. This implies that the customer in the worst case has to put only name, surname and credit card number on the payment processor interface (the ideal would be a payment interface totally integrated with our website)
I don't want to force the customer to register to any third party service
It should work nicely with Ruby on Rails
It should work for non US-based companies and should support multicurrency payments
What are the options out there?
Thanks.
I'd recommend you look at our product Balanced. It's built to solve exactly this problem so I think it's a good match.
At a high level payments in are done via credit card like a normal payment processor, funds are deposited into an escrow account which is a sum of all funds collected - all funds disbursed. When you're ready to push funds out you can currently pay out via next-day ACH (US only) but we're building out international support which sounds like it would be useful for you.
I believe it matches your other requirements:
there is no requirement to send users offsite, they do require accounts but you can create and edit them via the API.
Balanced has an excellent ruby gem
You can split up the payment, taking a cut from the proceeds as profit
Balanced provides you with a merchant dashboard for you and your customers to get a head start but you can build the exact same thing via API access.
One area where it's not going to meet your requirements is multi-currency charges. Currently you'll need to charge in USD and convert.
Check out https://github.com/drhenner/ror_ecommerce It doesn't have all the features you want but will give you a big head start.
Basically active merchant will connect to most gateways. You need to add the custom code. Look at the video for more help http://ror-e.com/info/videos/1
Related
I would like to build an app that shows me the price history of products and notifies me when the price reaches a certain limit.
I know that some of these things already exist, but I'm also interested in learning how to build them and trying out some technologies.
This is my question:
how do I get access to the Amazon Product API without having a website?
Right now, there are two Amazon APIs:
The older one is called Amazon MWS. You find its documentation here.
The newer one is called SP-API (abbreviation for Selling Partner API). This is their main page.
The access to both is only possible after registering as a professional seller (sic!), which costs a monthly fee (about USD 40). After registering as a seller, you then have to additionally register as a developer within your seller account.
If you do not want to pay monthly fees or register, you could also try webscraping their website. Here I do not now, what their policy is.
New here and i hope i am in the right place to ask my question. We are having problem with submitting our app to Shopify App Store.
We have an app where people can create their own designs on our physical products and sell. So we can produce their products and dropship to their customers. There are many apps to that.
Problem is they forcing us to use Billing API for our product charges. They take 20% of commission which our margin is not that much. We are wholesaler and we our margin is super low. We use (well we were planing to use) Stripe for products charges, which is 2.9 % commission.
And Shopify Apps Team member is keep asking me my margin, and says: "We are requiring that all apps use the billing API, but I might be able to make an exception since it seems like your business model isn't compatible. If an exception is made, you will be required to sign a revenue share agreement based on your margins"
All other App (in our business line)they charge their customers with 3th party payment processors and i have spoken with some of them they say they never heard about it and they don't share any revenue (apart from membership fees) with Shopify.
Any idea about this?
Thank you so much for you help.
Shopify is charging 20% of the cost of the app not 20% of the cost of your finished products. I don't know if your app can be free and still in the app store but from what you have written free would work since you will actually make your money on the goods. Just bill normally for the orders you receive
I'm looking for a way to allow our clients to do recurring payments to discount these payments based on the credit in their account which can be earned or deposited in many ways. For example, if they need to pay $20 and have $5 in credit, I would like to only bill the remaining $15 automatically without any need for additional website visits.
Looking at the documentation for PayPal's REST APIs, I don't see any clear way to do this. Is the only way to do this to send them a refund automatically? Or is there a way to get approved to bill clients up to X amount per month but allow us to bill under that amount. I thought billing agreements would allow for this, but after reading the documentation, I'm unable to figure out a way to do it. If it's possible, could someone walk me through what API calls would be needed to do this?
Thanks for any help you can offer.
There are a couple of different ways you could do this sort of thing, but I would avoid the REST API for now. It's still too new and doesn't provide as much functionality and features as the classic API.
Within the classic API, you can use either use Preapproved Payments, which consists of Preapproval and Pay APIs, or you could just use Express Checkout and/or Payments Pro with Reference Transactions.
Either way you'd basically be building your own recurring payments system where you'd setup a billing agreement and then your app would trigger the variable amount payments accordingly.
We are about to develop new mobile application that requires the end user to fill his payment information, which will be redirected to a third party’s portal to pay for a certain services through the application ( using Web Services )
user send billing information using web services , Is this legal for apple ?
It's OK to integrate 3rd party credit card payment systems in your app (for example PayPal, Amazon payments, etc. or your own system) as long as you do not sell services, extensions, etc. to your app. As you say you're going to sell physical goods, it is OK for Apple. Amazon app does the same thing. Btw it is even explicitly prohibited to use in-app payments to sell physical goods.
EDIT: more answer to the detailed questions in the comment
IMHO (see disclaimer):
Shipping fees of physical goods and signup fees for your physical service are NOT services or extensions - in the sense that Apple uses it, it applies only to some additional features to your application, for example a new level in a game or a new map in a mapping app
to be legally store, transmit, process credit card information, you will have to be compliant to the Payment Card Industry Data Security Standard. Here Apple has nothing to do, but both Visa and Mastercard (and maybe also other card issuers) require that you implement these practices if you wish to process credit card data of their cards
this last requirement might be tricky so I really suggest you to look for some ready solution instead of implementing your own. See also the first answer to this question: Use In App Purchase For Real Goods
DISCLAIMER: I am not a legal authority or somebody from Apple so I can give you just hints but not a legal advice - will have to ask a lawyer for an "official" answer :)
what are the must have functionalities for an e-commerce web shop?
e.g.
unlimited categories and sub categories
multiple categories per product
multiple product images
product consumer ratings and comments
payment gateway integration
delivery service integration
Best Sellers
Newest Products List
discount facilities
promotional facilities (buy one get one free)
I know we shouldn't just link to elsewhere, but this link is within stackoverflow. I'll just quote it all here:
Do you need to build one at all? Most of this has been done for you in
various shopping cart packages
including google checkout,
oscommerce, and others, but if
you must take the plunge try to at
least think about the following...
Secure session for users
Storing 'items' in the cart via the session / cookies
Payment processing
what external systems do you interface with
what kinds of payments do you accept
what currencies do you accept
Some kind of dispatching system for when a purchase occurs
If a purchase occurs, who is notified to mail out the items?
where is the purchase logged?
Interaction with an inventory system of some sort
is the item in stock?
what to do when out of stock?
Total / shipping calculations
how much do you charge shipping for different customers/destinations
where do you want to ship / where will you not ship
A shopping cart is far more complex a
concept than it appears to be. The
specific answer to these questions
will depend on what kind of
organization you are working for. Big
company? Small startup? Family
business? High volume vs low volume?
Etc.