Currently, I use PayPal for payment processing. Almost 90% of the items are sold for $.99 and would like to use Paypals's Micropayment account, but PayPal states "support for Micropayments to merchants for US to US, GB to GB, AU to AU, and EU to EU transactions". My company is located in the US but the customers are very global. Does this mean using Micropayment option, I can't take payment from someone who lives in Europe or outside the US? Currently I am using the regular account and I am paying $.34 for each sale, which is very unprofitable. Are there other payment processing service I can use with lower fee?
Thank you.
Unless you have insanely high volume like fast-food chains do, it is very difficult to obtain a merchant account where the transaction pricing is feasible for micro-payments. Most providers will suggest an aggregation model where you sell your content but only bill your customers periodically, i.e. bill them once a month so that several purchases are bundled together, making the transaction fees less of an impact.
Here is one provider offering such a model:
http://www.allcharge.com/services-billing-micro-payments.asp
I do not work for the above company (in fact, I work for a payments company that does not offer micropayments).
Not the answer you were hoping for, I'm sure, but hopefully it helps.
Take a look at www.carrot.org which runs a micropayment system. Customers using carrotPay load funds into an electronic purse - WebPurse - and can make payments with 2 clicks if you have a Carrot buy button installed on your site. The buy button can be set up along side other payment methods on your site. The webpurse automatically converts the currency so if your client has GBP in their purse, they will be presented with a GBP price for authorisation but the merchant receives USD if this is the currency they used to price the product. Charges work out at 6% - 10% maximum. The Webpurses can also used for some kind of loyalty schemes as they will store many different currencies, real and virtual. If you would like more information please contact andy#carrot.org
Take a look at Google's In-App Payments. The fee is a flat 5% which is great for transactions
http://code.google.com/apis/inapppayments/
I do work for Google, but I've taken a look at other similar products and can honestly say that In-App Payments is a very competitive product.
You can use Randpay - scalable micro-payment system, based on blockchain: https://medium.com/#emer.tech/randpay-6a028f16c82a
Related
I have a client that wants a site that hosts sellers selling items and allows buyers to purchase the items. She wants all the money transactions to be between the buyer and seller and she collects a percentage of the sale. She wants her percentage to be automatically put in her paypal account. Kinda like eBay for example.
I have used paypal standard with buttons but have never done anything like this. Does anyone have any suggestions about how I would get started and/or how this is done?
Thank you for your suggestions,
Greg
Many people would (and probably will) recommend using some sort of split/chained payment solution, but I will just point out that the site you mention, eBay, does not use split payments. eBay sellers register with eBay; eBay faciliates the sales and bills the sellers for their fees. You can do the billing through invoicing, or via preapproved payment/billing agreements (which allow you to collect from sellers without them having to send you each payment).
While this solution requires you to do a little more work (tracking sales & billing) it is a lot more flexible.
I m planning to integrate micropayment in my ASP.NET website. I need to use PayPal to achieve this.
The cost of the service I deliver is low, about $1 per month. I'd like to know more about PayPal service for this kind of cheap transactions.
How much does PayPal hold for each $1 payment ? I found this explaining the PayPal conditions for micropayment. Any feedback on this ?
Plus, how does PayPal handle currency conversion ? My service is worldwide, so I want my users to be able to buy my product not only using dollars, but euros or another currency.
Thanks
In the link you quoted the fees section is expandable and you can see the Micropayments pricing:
5% + $0.05
Signing up for it doesn't require any vetting or contract changes. Contact Customer Service and they file a request to a team that enables Micropayments. Should be done within a few days.
Currency conversion and cross-border transacitons are also in this page:
International Sales: The pricing table above applies to domestic payments in US dollars. There's an additional 2.5% charge for any currency conversion and a 1% charge to receive payments from another country.
If you decide to charge your buyers in USD only, they will be able to choose if they wish he card issuer or PayPal to convert the money. Most won't even notice the conversion took place and it will make your reconciliation much easier.
I'm new to online payments and would like some opinions on my task. Here is the scenario:
I have a website where people buy and sell digital photos. A seller has a photo and wants to sell it. They create an ad on the site and upload the photo into the website database. Buyers looking for photos come to the site and buy them. The buyer pays the asking amount and then can download the photo. As the middleman, I'd like to charge the seller a fee or percentage of the selling price. The buyer shouldn't pay any website fees, just the selling price.
My question is - what is the best way to do this? I dont mean programmatically, but what service should I be looking at? As far as I know PayPal wont work because of their fee structure. Im told Amazon payments would work but its sort of a hack. The seller has to set up a business account and then tie their item to my website as a third party sales venue. Is there an easire way to accomplish what Im trying to do? Of course keeping fees as low was possible.
This will work perfectly fine with PayPal.
PayPal offers Adaptive Payments as of a while ago, which allows you to specify 'primary' and 'secondary' receivers (up to 10 recievers per 1 transaction I believe, from the top of my head).
You could thus use Adaptive Payments to set the photographer as the primary receiver, set yourself as the secondary receiver and optionally move the transaction fees onto the photographer as well.
Have a look at this page for more information.
I wanna build a web store for selling people's second hand products.
A customer adds the products into a shopping cart.
He/she pays (credit card, bank account) for it and I get the money.
The seller sends the bought products to the customer.
I get send the money to the seller (and have taken a fee for it).
People tend to mention Amazon's, Google's and PayPal's payment service but recently I came across services like Chargify and Recurly.
My questions:
How do these two differ from the other three?
Which one would support the above mentioned transaction process?
How should I set up the above transaction process?
The "big 3" require an account. How do I charge with just a credit card or bank account only?
Thanks!
Thanks for thinking of Chargify.
We're not the right thing for your need... we focus on helping a business manage many things involved in recurring billing of customers.
For what you want to do, I think one of the "Big 3" is the way to go. You've got the extra "wrinkle" of this, however: you're essentially collecting money on behalf of each Seller, and each Seller may be selling very different things and will have different levels of honesty, etc.
All of my experience is with merchants that have a traditional merchant account and payment gateway, which together allow them to charge credit cards. But the banks that issue merchant accounts want to know what each merchant (each Seller) is about. I'm 99% sure the banks dislike a single merchant account being used to sell / collect credit card payments for more than one merchant.
Anyway, to the degree that it's useful, I wrote a blog post last year about merchant accounts and payment gateways. It may be helpful to you as you explore options:
https://lancewalley.wordpress.com/2010/06/22/merchant-accounts-payment-gateways/
See my answer in Online payments for a middleman.
PayPal Adaptive Payments allows you to accept guest payments, without requiring buyers to have a PayPal account.
Another thing to think about is regional availability; Amazon / Google may sound interesting, but are not very useful if you don't live in the US or UK. Whereas PayPal Adaptive Payments is available pretty much globally (with the exception of a few countries where PayPal hasn't launched yet).
Which payment gateway should I choose from among Authorize.net, PayPal & Google Checkout?
Is there anything wrong if I provide all ? I'm planning for express checkout methods in all the three services, the direct credit card accepting service.
The more choices you offer, the more choices your customers have, so no, there is nothing wrong with offering all three.
If you potentially have customers from the EU or Asia, you may want to investigate options that are popular in those regions as well.
Keep in mind, PayPal tends to freeze money in account for some reason and have huge problems even answering email with 24 hours.
Paypal is of course the most well known and respected, however the answer actually depends on the amount of revenue your company will make (monthly and yearly averages), the average price per transaction and the number of debit card vs credit card payments you are likly to take. Without these figures it's nigh on impssible to determine which one is cheapest for you.
Authorize.Net is only a payment gateway, not a payment processor. You need to have a US based merchant account to use with Authorize.Net.
Paypal and Google Checkout are third party payment processors. They essentially are the payment gateway and merchant account rolled into one package.
It's worth noting, from the research I've done, using PayPal is cheaper than credit card processing directly. They charge less of a fee (I'm assuming because they process everything themselves, and don't go through some third party to get to the credit card company).