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.
Related
I'm a Freelance developer creating a site for a start-up company.
Getting PCI compliant at this time is going to be tough, since the site is still in major development and the funds are quite short.
The situation is this: They want to accept payments on demand in a fast and easy way. This is going to involve punching an id followed by a PIN into a virtual pinpad. This should process the transaction, charge the card, and be done. Because we are not currently PCI compliant, I would like the security to be as follows:
User, in Account Management, can click a link to redirect to the third-party payment processor (We are currently using Authorize.Net). On this page, the user enters their card information followed by email/some form of ID. Their card is saved through this third-party, and the third-party sends us their ID for the user as long as the user email (Or whichever identification used on our end). Now, when the user wants to create a transaction, we send the User ID, our API Key, and the transaction Key used by the third-party as well as the amount to charge. They charge the account and all is good.
Anybody have experience in this? Is this possible? Other solutions are welcome. Again, the company is slightly low on funds, and the transactions are usually going to be ~$10. They are currently working through 100% cash right now and averaging about 30 transactions a day, which is expected to increase drastically over the summer.
Unfortunately, with the new DSS 3.1, you may still need to perform a SAQ A-EP. Part of the requirements for the SAQ A-EP are:
Your e-commerce website does not receive cardholder data but controls how consumers, or their
cardholder data, are redirected to a PCI DSS validated third-party payment processor
Even though your site never takes or processes credit card data, since your site does perform a redirect, that redirect could be changed to point to a malicious site.
Further information can be found in the SAQ A-EP.
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
I need to integrate a subscription solution to my rails application. Paypal seems to be the best option (for non US Merchants).
I need to have
Ability to accommodate monthly and annual billing
Ability to suspend, cancel accounts etc
Deal with out-of-date card details or failed payment
just as mentioned here:
Recurring billing with Rails - what are my options?
I've come across various Paypal solutions like:
** Express Checkout
** Website Payments Standard
and various implementation options like ActiveMerchant, paypal_recurring gem
Just wanted to know
[A] - which Paypal option is the best one for subscription based billing with conditions 1-3 above and below additional condition:
for non US merchants
[B] - what are the best implementation options as in ActiveMerchant, or the paypal_recurring gem?
I would recommend going with Express Checkout and Recurring Payments. Specifically, you'll be using SetExpressCheckout, GetExpressCheckoutDetails (optional), DoExpressCheckoutPayment (optional), and CreateRecurringPaymentsProfile depending on exactly what you're doing with your application.
SEC will return a token that you'll use to redirect the user to PayPal as well as in following API calls.
GECD is used to obtain buyer details (ie. shipping address, address status, payer status, etc.) from PayPal now that the user has signed in and agreed to continue.
DECP would allow you to finalize a one-time payment that includes shipping and tax info, item details etc.
CRPP allows you to setup the recurring profile including one-time initial payment, trial amounts, regular amounts and periods, etc.
Then behind that you can use the UpdateRecurringPaymentsProfile API to manage the profiles programatically.
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
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.