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.
Related
I am working on a Rails Application where Users can buy Items other Users shared previously.The payments should be flexible to allow the User who shared an Item to get the money a buyer pais.
1) Is it possible to create Flexible Paypal Payments (Different Seller, different Price for each Item)?
2) Can you use the PayPal IPN with Donations to check whether a buyer paid or not?
3) If not, what is the most efficient way to achive that goal?
Thanks in advance for each answer! Please tell me if you need additional information.
Here's the way I'd approach this:
Is it possible to create Flexible Paypal Payments?
Different sellers: Do you want them to be able to receive the payment directly in their Paypal? If that's the case, you'd need to provide them the details to create a Paypal merchant account and securely store those details, but I don't think that's the approach you want to take;
Most payment solutions provider gives a way to send payment to multiple vendors/merchants, which you may instead want to set up or even in your application, you can set up a kind of payment stuff to ensure that integrates with Paypal's API to pay your vendor soon as you receive payments for items.
So, yes it's possible, the different sellers could be tricky, but all other things are possible!
Can you use the PayPal IPN with Donations to check whether a buyer paid or not?
Absolutely, that's one of the biggest benefit of the IPN is that your application gets to know on time if someone has made a payment. You only have to validate this record with Paypal and, not like it's often necessary compare the payment amount
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
This post references: https://github.com/andrewculver/koudoku
I'd like to use Koudoku for one time payments as opposed to recurring billing. I do not see any way to do this.
Koudoku is specifically designed for recurring subscriptions.
If you're just looking to do one-off payments, I recommend just following the standard Stripe tutorial for a payments page.
To support returning customers or additional purchases, I recommend simply using Devise for authentication and then saving whatever the resulting Stripe customer ID is from the first purchase in the user model, so you can run additional charges against the same card in the future.
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.