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?
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
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With