I am looking to implement an opencart solution for a client. They require a peer to peer payment system that allows a user to buy a product from multiple vendors. In other words the client will not hold any stock. They will just facilitate a transaction between the buyer and seller and collect a commission on each transaction. Has anyone here implemented such a solution in OpenCart?
i have paypal adaptive method, but i want credit card side also????
Thanks!
To process a card transaction (credit- or debit-card) there needs to be someone to hold the funds between the parties. It can be a e-wallet or a merchant with an account with an acquirer. The acquirer in turn talks to all the card schemas to make the transfer possible, often sorting out a few other things too, like fraud-screening.
As far as I know direct p2p between card accounts are not yet available, at least across different banks. So I think you still need a payment gateway to process it, and not to worry about the Payment Card Security (PCI) regulations.
Related
I am a college student and I want to launch an online store for dropshipping. I am allowed to have one credit card, where I live, say Mastercard. But for the customers convenience I would like to enable VISA, Discover, Mastercard, American express, Debit card, and PayPal checkout. I know that there is a PayPal credit card that allows payments from all these cards but it requires a business license, which I am not allowed to have as a student. Is there a way I can receive payments from the above mentioned cards to a Mastercard? If there is a better solution to my problem I would like to hear it from you. Thanks!
When you set up an online store, you will also be signing up with a Payment gateway that will be collecting money on your behalf and transferring it to you. In this way, you will be able to set up your store to be able to accept any payment methods supported by the payment gateway(s) that you set up, and any money you make will be transferred from the gateway to the account that you registered with. This might be a credit card or directly to a bank account depending on what the gateway supports.
Using a trusted payment gateway (such as Stripe, Braintree, PayPal, Authorize.net, etc.) will let you focus on your store and not have to worry about accepting credit card information directly, and you will get your earnings transferred to you regularly in a form that you can accept. Note also that taking credit card info directly comes with a host of security concerns and regulations. By using a payment gateway you will never see anyone's credit card info directly, so you won't have to worry about all the security and legal concerns surrounding that. The gateway companies make their money by taking a small transaction fee for each purchase, but this fee is definitely worth it to get your business started.
My use case: buyer buys service from seller, our app facilitates and guaranties the transaction. It should work in the way that buyer sends the money to us, we check if buyer received the service, in that case we send the money to seller. Otherwise we refund the buyer. Important is to have 2 payments solutions for the buyer: paypal account and card payment without account. The whole use case is international.
I'm testing this in sandbox environment.
Possible solutions:
Adaptive payments - Delayed chained payments:
Works fine. Disadvantage is that the seller must grant us permission so that the refund works. The problem here is that the permission api is under maintenance, so i am waiting for all the changes https://developer.paypal.com/docs/classic/permissions-service/integration-guide/PermissionsWhatsNew/ . Is this big deal?
Express checkout Authorize/Capture + Mass Pay:
Works OK. Advantage here is that in case of refund (void after authorize) we don't have to pay the fee. Disadvantage here is that I'm not sure if authorize holds the funds, so that even buyer without account paying with card cannot touch the money and I can capture them in 3 days. Another issue is that when I authorize 40$ from PayPal account with 30$ balance, I capture the whole 40$. How come?
I have no previous experience with PayPal I now the app should work on international scale. Please if you have any tips, articles or practical experience with this use case share it!
EDIT:
Delayed Chained Payment is great. I solved the issue by making my application the secondary receiver and the seller primary one. Seller must grant a permision to my app in case of refunds, but there is no better way.
However, now the issue is that when buyer pays without account (Guest Payment - with card) all receivers must be Business or Premier account holders:
Each receiver of a guest payment must be a verified PayPal business or premier account holder.
Source: https://developer.paypal.com/docs/classic/api/adaptive-payments/Pay_API_Operation/
The issue is that in sanbox it works even if the primary receiver (seller) is NOT Business or Premiere account. What is wrong?
1) Do you have yourself set as the primary receiver? If so, I don't think you would need to have permissions granted unless you had already run ExecutePayment to push the money to the secondary receiver account. If you're refunding before that happens you shouldn't need permissions (though I haven't tested this specifically, so I could be wrong.)
2) Regarding the fee, if you refund a payment that went through Adaptive then PayPal would refund the fee back to you, so you're not really gaining anything here as far as that goes.
The authorizations can be tricky. I theory, the authorized funds should be guaranteed for 3 days, but you still capture within 30 days (or maybe 60) even though it may or may not have funds available at that point (it would simply succeed or fail).
You could run a Reauthorization after the first 3 days to get yourself an additional 3 days of guaranteed funds, but I don't think you can do that more than once.
Much of that depends on the card issuing banks, though. Even though PayPal's docs may specify certain things regarding how authorizations work, if the card issuing bank has different rules associated with their credit cards that could throw things off.
As for why a $40 auth would work when the PayPal balance is only $30, I think that may be because of secondary funding sources. If you have bank account and/or credit cards setup in the account, PayPal would assume it can pull from those sources when the time comes to capture if the PayPal funds alone don't cover it. Depending on your use-case this may or may not be ideal.
You are mixing multiple concepts with this question. There are different PayPal PAYMENT products (adaptive with chained payments vs express checkout) and then there is the question of authorizations vs immediate payments.
Agree with Andrew that fees in the refund case is not the right basis to choose a solution. Much more significant is what the sender & receivers will see in their accounts (payments to/from you, or from/to the other party?), simplicity/reliability of the overall system (can an error on your side cause failed or multiple payments?), liability, and even regulatory questions (e.g., are you acting as an escrow service?).
If PayPal gives you an auth from a PayPal buyer it means that PayPal guarantees (with certain very limited exceptions) that it will honor a capture of those funds within the specified time and amount limits (which can vary with the specific scenario). PayPal might make that guarantee based on the sender's balance, credit cards, bank accounts, or combination of factors. You as the recipient needn't care - that is between PayPal and the buyer. (And it's PayPal's limits/conditions which apply to that auth, NOT the conditions of the sender's underlying credit card/bank/etc; PayPal protects you from that complexity.)
In contrast if the auth is from a card network rather than a PayPal account (ie the user gives card info rather than using a PP account, whether or not PayPal is your payment processor), then that network specifies and controls the conditions of the auth.
PS: if you are waiting for Adaptive Payments changes, you may have a long wait. Release 89 was quite some time ago and PayPal's priorities are on the RESTful APIs, not Adaptive.
I working on an e-commerce site where I need to do something like this.
When the users is on payment page, he should be doing the following things:
- pays a fee
- authorize the payment of an amount (which could vary, but not with a big amount...)
Up to here, everything goes find with PayPal Direct payment system.
But I need more. I need that the authorized amount at some point to be directly charged by another seller (or transferred)
Any chance I can do this with PayPal Direct (such the the payment would still be made in site)? Or is there any other method?
If you're receiving the money via DoDirectPayment you could use MassPay or Pay to send funds to a 3rd party. If you want the split to happen within the original payment you can use Pay by itself and set it up as a parallel or chained payment. See the Adaptive Payments documentation for more details on that.
(Disclaimer: I am employee) Balanced will work for your use case
capturing cards directly without sending user to a third party site
paying out to a merchant of your choice via ACH payout at a later point in time.
The caveat is it's US only so if your outside the US let me know and I'll see if I can find any other options for you.
I have a bit of experience setting up online payment systems that accept credit card numbers and then pass them over to a gateway for a one time payment.
However, I now need to setup a system that can handle automatic recurring billing - where a user provides their credit card number and is automatically billed on a monthly basis from that point forward.
I am wondering what the best way to approach something like this is? (I notice that Paypal Payflow Pro does have a recurring billing feature, but I am a bit unclear on how it works.)
Any advice on the best method / service / gateway for implementing recurring billing? If possible, I would greatly prefer to avoid keeping a local record of credit card numbers for repeat processing.
Thanks (in advance) for your help.
There's a midpoint between building your own recurring billing and Auth.net's ARB or PayPal's recurring billing (both of which have their disadvantages). There are a number of providers that handle all the details and complexities of recurring billing, and simply report the charges to your payment gateway for processing at the interval you determine.
The most critical piece to look at is which services to credit card tokenization and support credit card data portability - this will ensure that your customer data isn't locked in with a billing provider and that you can take it with you if you choose another provider in the future. This also means that these providers store the customer credit card data for you, so you can greatly reduce your PCI compliance.
Take a look at Recurly (Disclaimer: I manage their customer and technical support) and Braintree. Both services will handle your recurring billing, credit card tokenization, and support credit card data portability.
Recurring billing is easy to handle and offload to a third party if your recurring amount is constant (e.g. the amount a user pays never changes in amount or frequency). Services like Authorize.Net's Automated Recurring Billing (ARB) and Paypal Payflow Pro recurring billing allow you to have those companies handle the actual recurring payments which means you don't have to store credit card information on your servers or even do anything once the subscription is created through their APIs.
If your subscriptions will vary in terms of cost or frequency, you'll need to use a service like Authorize.Net's Customer Information Manager (CIM) to create payment profiles for your customers. Basically you're storing credit card information on Authorize.Net's servers and whenever you want to make a subscription payment you tell Authorize.Net to charge the amount due to that payment profile. The drawback to this is you essentially have to build your own subscription system.
You usually find the recurring billing features in middleware gateways like Payflow Pro. In that case, it is invoked by a variation of the API you use for card processing. You usually set up the time span between billings and they perform the billing. You usually then reconcile the billing with the report that your processor sends you each month. In some cases, the payment gateway will post a notification to you that the billing was performed. You still have to reconcile the payments with the processor report because sometimes the notifications fail.
Canceling the recurring billing is also another API call.
If your gateway doesn't have the recurring feature, you obviously have to set up the billing yourself. This of course leads to storing card info and so forth. In this case, you usually tell the processor that it is a recurring transaction (which the gateway will do for you) so you get a discount on the transaction fees.
First, let apend the statement above "...tell the processor that it is a recurring transaction ...so you get a discount on the transaction fees". The true cost of credit card processing is a percentage fee and a per item fee based on the type of card presented ( and some other factors I won't delve into here.) The point being, on a wholesale price plan, the price would be the same regardless of whether it was recurring or not because there are no special rates for 'recurring' in interchange. But I digress.
"Any advice on the best method / service / gateway for implementing recurring billing?"
Don't take on storing credit card data no matter what. You can't afford the liability.
The right choice depends on several factors.
As to credit card portability, has anyone gone to Wells Fargo/ First Data and gotten their data out? (Braintree ISO/MSP). I guarantee it won't be pretty no matter what so I would focus on the right long term solution, rather than the exit strategy, though it will certainly weigh in.
Here's questions that need to be answered:
How many transactions per month? For very low volume, maybe a few hundred, pick paypal pro. It's easy to get into/ out of.
Are people more likely to pay with consumer cards or business credit cards? Interchange optimization is important if business cards. (CenPOS automatically optimizes the transaction for lowest interchange qualification, paypal and authorize.net do not)
What methods does my client accept payments? self pay on internet only? Phone orders? Mobile payments (special events or retail)? Choose a gateway that fits all their needs.
Do you need to charge on specific days- ie the 1st and 15th? Or any time? If on specific days, how will you prorate? Check the answer against the gateway flexibility.
What happens when a card expires?
What happens when a transaction is declined?
Who will need to see the payment data for customer service? How will they access it?
Determine your needs, then figure out which ones meet them.
For the record, CenPOS is the most robust solution, but may require more steps to integrate since they are newer to ecommerce.
Disclaimer: I've been a business user of paypal and authorize.net for probably a decade and more recently CenPOS. I'm also an authorize.net reseller, and CenPOS direct agent.
Just a heads-up about Payflow Gateway's Recurring Billing:
Their Instant Payment Notifications (IPN) is a fantastic feature, but only applies to their legacy APIs. For the time being, THE ONLY WAY to be notified by PayPal of a successful (recurring) billing transaction, is by inquiry. You will need to maintain a schedule to inquire, and send an individual inquiry for each, scheduled recurring billing transaction, one at a time. PayPal will not notify you if, for example:
A transaction is approaching
A transaction has occurred
This transaction was successful
This transaction resulted in fault
A credit card is approaching expiration
A dispute occurred
... and so on.
In my opinion, this renders their service useless.
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).