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
Related
I have buyer and seller in my platform.
When the buyer purchases a product, at the same time the amount should be captured from his account, and on product delivery the seller should receive the amount and admin gets 10% as platform charge.
This implementation is very easy in stripe but I want this to implemented in Russia, France, and Germany and stripe is not supporting these countries.
So, I want to go with PayPal.
I am googled and found that adaptive payment is used for that.
But on the paypal documentation page, it is written that adaptive payment is restricted. Paypal's documentation is very confusing and limited.
I want some can help me on that or can share some links for my better understanding.
Unfortunately, there is not a "quick and easy" solution available right now.
They have added the Marketplaces API which will replace what Adaptive Payments was doing, but it's not ready for public use yet.
You might be interested in this article about PayPal split payments with Express Checkout. It outlines a few alternative methods to get this done.
Can't understand which PayPal API to use.
I have Rails app and I'd like to accept credit card recurring payments via PayPal. At first I was thinking to use Express Checkout API that supports recurring billing and can work even if a user doesn't have PayPal account. But then I saw that their official ruby gem merchant-sdk-ruby https://github.com/paypal/merchant-sdk-ruby will be deprecated:
This Classic SDK is not actively supported and will be deprecated in
the future. For full support on new integrations, please use the Ruby
Rest SDK
So I don't want to use something that will be deprecated soon. But I can't understand whether I can use REST API to accept credit cards without being PCI-compliant.
I'd like to redirect user to PayPal where he could enter his credit card info and return back to my site like in Express Checkout, but I see only examples where credit card info is collected on my site and passed to PayPal via API that implies more security headache on my site.
UPD: I found some information regarding this question in Accept a PayPal payment section of REST API documentation that is a bit odd because I expected to find it in Accept credit card payments section. They say:
Important: To receive Guest Checkout payments, which allow credit cards, ensure that PayPal Account Optional is enabled on your account
settings. For example, here is the path for US accounts:
Profile > My selling tools > Website preferences > PayPal Account Optional
But I'm still not sure whether it will work in my case. Now I have the following question:
Can I use Guest Checkout feature to accept recurring payments?
Can I test Guest Checkout in Sandbox? And if I can what credit card number to use?
Can I show by default form for entering credit card info when user gets to the PayPal site rather than for entering PayPal credentials?
Ughh... why it is so complicated?
There are couple of samples in PHP code, that could help you understand recurring payment options in REST API.
https://github.com/paypal/PayPal-PHP-SDK/tree/master/sample/billing
Or you could follow up the docs on : https://developer.paypal.com/webapps/developer/docs/api/#billing-plans-and-agreements
I will look into this specifically and get back to you
For trying it out on sandbox, you can create an account here at https://developer.paypal.com/webapps/developer/applications/myapps You need to create an app, and it would generate a valid credit card for you.
This may be very unlikely to do, but I can ask the internal team if they know of any such option.
Railscast #289 is on this. It requires that you sign up for the pro version. Looks pretty involved but he walks you through it.
I was wondering how can I send customer credit card data from ecommerce website to Quickbooks. There are some concepts i am confused.
From my understanding, basically I can process credit card on my ecommerce website using "Merchant Service for Web Stores" API, and i found there is a "Payment wallet" function, is the connected to customer credit card info on desktop Quickbooks? What's the proper way to process credit card for my ecommerce site and at the meantime sending the customer credit card data into my desktop Quickbooks, saved there and for future use?
Any help would be greatly appreciated.
ps: The ecommerce site is by PHP
I was wondering how can I send customer credit card data from ecommerce website to Quickbooks.
Are you sure you actually need the credit card data in QuickBooks? You should know that if doing this, you likely won't be PCI compliant without jumping through a lot of hoops - and remember that storing credit card data on site is incredibly dangerous from a litigation/security/legal standpoint. You're setting yourself up to get sued when that data gets stolen.
From my understanding, basically I can process credit card on my ecommerce website using "Merchant Service for Web Stores" API,
Yes.
and i found there is a "Payment wallet" function,
Yes, and this is what you should be using. It securely stores the data with Intuit instead of with you, so that you are still PCI compliant and the card data is safe.
It allows you to push credit card data to Intuit, and they return a unique ID value to you which you can use to charge the credit card at any time in the future, without actually having to know the card number itself.
is the connected to customer credit card info on desktop Quickbooks?
No, it's not.
What's the proper way to process credit card for my ecommerce site and at the meantime sending the customer credit card data into my desktop Quickbooks, saved there and for future use?
You don't want to do this. There is no proper way to do this. It's a terrible, insecure practice. Don't do it.
Instead, charge the credit card via the QBMS API, and then store the credit card in the payment wallet and store the payment wallet unique ID in your database. You can then write a simple program that lives and uses that unique wallet ID to charge them again at any time.
Since you're using PHP, this is the best place to start (disclaimer: I'm the author of the below code):
open source QuickBooks PHP DevKit
Specifically, you'll want to look at the QuickBooks Merchant Service examples:
PHP - charge credit cards with Intuit QuickBooks Merchant Services
PHP - store credit card info securely with Intuit QuickBooks Merchant Services
Before you can really utilize the code, you'll have to go through a very simple registration process with Intuit (register in DESKTOP mode for easiest implementation).
Quick-start for Intuit QuickBooks Merchant Services with PHP
I've seen a few questions related to API specifics and paypal. Generally speaking if I'm going to offer my rails app as a subscription based service, what are the pros and cons of the different payment systems available on rails?
My main concerns are:
Avoiding PCI compliance, and not storing any credit cards on our servers
Easy API with recurring payments
Looking professional (not showing someone paypal branding anywhere as an example)
Paypal seems to have some "PRO" services that meet the above criteria, but I was curious about using a gateway like Authorize.NET directly?
What does Braintree offer above and beyond these?
What about Charify? It seems to be a layer on-top of gateways like Authorize.net with added dashboards and reports.
If the gateway or payment processor is storing credit cards for me, what happens if I want to take my 10,000 customers with me to a new billing service? Do they all have to enter payment info all over again? Is there a procedure in place so that different providers can move my customer / Credit Card database between them?
We've used Chargify and it's great for a couple of reasons:
PCI compliance: Chargify handles the storing of the credit card
Auto Charging: Will auto charge the credit cards after N months and a trial period
Dunning: Will email users if the charge fails, and try several times before expiring their account
Great Gems: the chargify gem rocks.
So I highly recommend using Chargify with Authorize.net
Cons:
Chargify adds about $0.10 to each account per month in addition to your merchant fees
I recommend this write-up which will clear up many of these questions.
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.