It is known that PayPal supports Adaptive(Chained) payments where one buyer sends the money and it is processed using one API account holder and the money can be sent to multiple
users.
My question is,
Does this approach also supports
accepting credit card (for the
buyer)?
Is it possible to capture the card
details at our website and use the
API (in the backend) without
redirecting to PayPal website
itself?
Here is my requirement...
I am running a website where sellers can sell their products and buyers buy them.
Seller sets the price and i get a commission
Eg. Person A sells Product P for $100. (My commission is 2%)
Person B buys P. and makes the payment in my website itself. Using Paypal API, i want to process B's credit card and charge him $100. Get my share of $2 and send rest of $98 to Person A.
thanks in advance,
Kannan R
Q1. YES it is possible to accept credit cards (PapPal Adaptive payments supports Guest Payments... where the user can enter their credit card details.
Q2. YES. In continuation of answer to Q1, the credit card details entered acts as the explicitly approved payment hence no need to redirect the sender to Paypal website for authorization.
http://www.paypal-labs.com/TechDocs/
This link explains things better, check out for the Guest Payments link..
Hope it helps.
rgds,
Sourcebits Team.
For Question #2:
While it is possible to capture the credit card details on your site, you should be aware that there is something called PCI Compliance, which is basically a set of rules you need to follow to ensure that your server and your software is secure.
It is not easy to meet PCI requirements on your own (time, consultant costs, regular inspections, understanding the rules etc.). And if the rules are violated or your server is hacked you could be fined hundreds of dollars/rupees per "lost" credit card details.
Search SO for some good information about this
Related
I am new to the payment area in app. Say in an App like Ritual or Open Table, I want the end user to be able to pay to multiple payees (just like the two apps I mentioned that you can pay to any listed restaurants), how can I achieve that?
From what I understand, each payee could have an merchant ID. If I want to make payment to multiple payees, do I have to obtain all their merchant ID? Or do I collect payment and then transfer to each payees?
Or, is it as app developers, we pick a payment solution (like Stripe or Braintree), and ask the participating restaurant to provide their bank info for receiving payment, and when the end users are paying, they pay directly to the restaurant's bank account through the payment solution.
Thanks.
Not sure if I understand this, why do you need multiple payee? Isn't the customer would just pay he merchant? As long as you can get the merchant ID and their account number, there should not be any issue. No?
Never mind the question, it's basically what I described in the last paragraph of my question
Blockquote
As app developers, we pick a payment solution (like Stripe or Braintree), and ask the participating restaurant to provide their bank info for receiving payment, and when the end users are paying, they pay directly to the restaurant's bank account through the payment solution.
I've looked at stripe connect and it forces each user to impute their Social Security number and etc. just so they accept payments for a item they want to sell.
Is there a less painless method where users can sell something on my site, receive monies, and buy from other users?
I tried using stripe alone and it pays me directly. Problem is I want user to sign up, sell something on the site, and get paid. I'm not sure how this can be done without having each user impute social security numbers, tax id, and other personal information if all they want to sell is a pen.
For financial compliance reasons (know your customer laws, anti-money laundering stuff), as well as protecting you from chargebacks and refunds, you'd have to use Stripe Connect and either Standalone or Managed Accounts. Unfortunately this means you'll have to collect certain information from the user like their bank account, date of birth, last 4 of their social, etc.
You can using their Transfers API, but you need to be in the US and so do they. https://stripe.com/blog/send-payouts-with-stripe
I'm looking for a way to accept money from credit cards and send money from my account to someone's credit card. Does anyone know of an API/Gateway that allows me to do this?
I'm working in Rails.
Thanks to all helpers!
Uri
First, I assume you're integrated into an online payment gateway such as Cybersource, Stripe, Braintree or anything else. You'd need that to process cards and each has its own integration documentation and gems.
Once integrated, you want to issue a REFUND to a credit card. This will send money to that card, debiting your bank account. Now the tricky part is that most processors demand a preliminary positive transaction to make a refund, which isn't your case. You're looking for something called stand alone credit or stand alone refund, which some processors require special permission for.
I've used this with Cybersource via Paymentech in the past. Have a look at page 45 in their documentation.
Alternatively, the easiest way to pay someone to his credit card is via a wallet. PayPal is the most popular wallet so you can use that, allowing users to draw their funds into a credit card.
If your comapny is big enough, it can also use Payout services such as Tipalti and Payoneer.
The standard gem for this is active_merchant.
You can transfer money to other accounts, if the gateway supports this.
See API documentation of transfer
Ok so there is this feature that I would like to implement on my site. Users can choose to donate money to a specific nonprofit (let's say Wikipedia). So they click donate and they choose the amount on the website, get redirected to PayPal website, complete the transaction, and then get redirected to my website AFTER I get some Instant Notification, with which I track that donation in my website database with the users info.
I looked up some Railscasts video about PayPal, but they were all mostly about e-commerce. How can I set up the system to wire the money directly to Wikipedia's PayPal account and how can I get the notification back? I really could appreciate it if someone could assist me with this.
P.S I am running the localhost server for now, will that be a problem?
What you're trying to do is called a "third party transaction" since the first two parties to the transaction are the donor and the recipient org (eg Wikipedia).
From my quick search of PayPal, I don't think it is supported. Even if it is supported, you'd need approval from each of the recipients to set it up. Eg see this Paypal 3rd party shopping cart article
Amazon Flexible Payments Service does support third party payments. Again, you'd need the co-operation of the recipients.
You could have the donors pay money to you which you would then turn around and donate to the non-profits. But to do so, either your donors would lose the tax deductions or you'd need to become a non-profit yourself. In addition, there would be two sets of transaction fees, yours and the recipients.
I am developing a rails site that will allow a group of merchants (5 - 10) to accept credit card orders online. I plan on using the Activemerchant gem to handle the processing.
In this case, each merchant will have their own merchant accounts to handle the payments. Storing banking information like that is not something I am a fan of. This could be solved by queing orders and allowing the merchant to log in to the site, input their credentials and process the order.
However, if I go that route then it seems to me that I would have to store the customers' credit card information temporarily until the merchant has the opportunity to log in and process the order, which to me is the greater evil.
Has anyone dealt with this situation? If so, what are the options available and what pitfalls should I look out for? In my mind, security customer credit card information is priority number one with the merchant account information a close second.
When you create the gateway object with ActiveMerchant, you specify the merchant's information. So I'd think that it'd work ok for your sw to place transactions on behalf of multiple merchants. Just keep their information in a db and use as needed. I'd recommend that you encrypt the merchant's information.
See gem attr_encrypted
I'm not sure why you don't want to store the merchant's information. Maybe you should say more about this.
If the merchant is using Authorize.Net, you just need the Authorize.net login and password for each merchant.
I'd recommend that you standardize all of your merchants on a single payment gateway such as Authorize.net or one of their competitors. It's hard enough dealing with one gateway, why deal with more than one. Also, you can easily become a reseller for authorize.net and ease the process for your merchants.
You're right, you really don't want to delay the credit card transactions until a merchant login in and supplies their merchant info:
Depending on how often the merchant logs in, you'd be breaking the merchant's card agreement about timely charges and batching.
You'd have no way to provide speedy feedback to the end customer--did their charge succeed or not?
You'd have to store the complete credit card number and other information. That requires high level of pci compliance. Not worth it. And you are forbidden from storing the CVV number, no matter what. So depending on your other information from the end customer, your charges would have lower qualification (higher transaction costs to your merchants).
My recommendation is to store the merchants' information. -- Encrypt it and do not let a merchant (or anyone else) see it. Only let the merchants replace their info, do not let them see the current info in order to edit it. That will lessen security risk of the wrong person seeing the merchant's info.