Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to take credit cards online for future payments?

I have a couple of clients that want to take credit card details on their website that they can then bill in the future (one runs courses and users are only billed 4 weeks before their course if they haven't cancelled and one runs a charity and each fundraiser is required to raise at least $3k, anything less than that is taken from their credit card). I totally appreciate they can't/shouldn't take and store the cc data on their own sites but I wanted to check your views on the best solution to do this. Obviously if the users were paying immediately online then it would be fine and any payment gateway could be used however they need to not bill them immediately and charge the cards an indeterminate amount of time in the future an amount (usually a couple of months later) that can only be established just before payment.

Am I right in thinking that the best way to do this is use some kind of variable recurring payment system (eg WorldPay's FuturePay, PayPal's automatic billing or Authorize.net's CIM service). These (and other similar services) allow for variable payments (although WorldPay/PayPal seem to be setup for recurring payments rather than one offs).

There also appears to be the option to use a company like http://www.braintreepayments.com/credit-card-storage to store the information. I would be most grateful if anyone could confirm how you generally go about dealing with this situation and whether you use the options i list above or if there's any better/more suited alternatives?

like image 526
deshg Avatar asked Jan 27 '12 10:01

deshg


2 Answers

If i am not wrong, Stripe.com can help with this. Check out this link about charging users from your server:

https://stripe.com/docs/tutorials/charges

like image 148
AAA Avatar answered Nov 01 '22 12:11

AAA


What you're trying to do can be done with most Payment Service Providers. You essentially want to perform a zero value authorization when a new customer signs up. This has two purposes, it will validate the card details (the payment gateway will send back a 'declined' or 'failed' if there is an issue with the card details), and it also stores the card details with the service provider.

The service provider will return a token id which is what you then submit on any future authorization/charge requests for that customer. With this model you need to be aware that cards can over time become invalid (as they expire, or user replaces a lost/stolen card etc etc).

'Recurring payments' is a slightly different set up and are generally more suitable for subscription based services with regular (eg monthly) payments. The advantage to recurring payments over the previous model is that the service provider should have the ability to automatically update card details on your behalf by using services that Visa and Mastercard provide to report back when cards expire, and to update old card details with new card details.

like image 4
PaulG Avatar answered Nov 01 '22 12:11

PaulG