Paymill Credit Card Validation

paymill_cc_validation.md

Paymill ideal scenario (for our webapp)

1. A user goes to the Profile area of my webapp.
2. The user then selects the tab Payment.
3. A form for collecting credit card data is shown in the user's Profile > Payment area.

The Profile > Payment form doesn't involve any transaction, it is just to "save" their credit card data (on Paymill servers, not ours) for later use, on future purchases on our webapp.

That way the user doesn't need to re-enter over and over his credit card deatils each time he wants to make a purchase, smoothing as much as possible the checkout process.

We want to validate the credit card details that the user is entering on the Profile > Payment form, without charging any fee.

The questions are:

• How can we validate the user's credit card data? Doing a preauthorization of a small amount (let's say $1) and then checking the preauthorization "status" property via the Paymill API?
• Does this method of credit card data validation work for any of the Paymill supported cards, including those which are 3-D Secure?
• In that case how can we avoid eventualy charging that preauthorization small amount ($1 in my example) to the client? Can the preauthorization be voided http://en.wikipedia.org/wiki/Authorization_hold#Voided_transactions via the Paymill API? Or is it a better approach to charge $1 the client, with no preauthorization, and then perform a full refund?
• Is there any other way of validating credit card data, prior to any transaction, with the Paymill API?

Many, many thanks!

Basically, pretty much all operations will require you to obtain a token, which can be transferred to your server. The process of obtaining this token is transparently the same for you, no matter which kind of credit card you are handling. The thing is: you'll be able to get a token from a 3-D Secure card only if you are going to perform a transaction. For non 3-D Secure cards, you don't need to perform a transaction. Unfortunately, you won't be able to know if a customer's credit card is 3-D Secure prior to calling the bridge.

As this is the only common operation for all types of credit card, this is the preferred way: create a transaction and refund it. The usual fees may apply, but once you have the token, you can pretty much create everything you need for a future charge: preuth tokens, payment method objects, ...

About the preauth: right now, we don't provide a way to delete or void a preauthorization. We plan to do that in future releases. But it's worth saying that a preath token expires after 7 days.

We do provide some methods on the javascript bridge to perform basic validation of the credit card numbers, but they are mostly checking the syntax. In other words: non-existent cards might get validated by the bridge if the data conforms with the standards. The only way to check if a credit card exists and is still valid is by getting the token.

Thank you Juraci for all these explanations.

Taking all into account, I would follow the "create a transaction and refund it" path instead of the "preauthorization" one for credit card data validation, as there is no guarantee that the "preauthorization" will work in all scenarios, for the following reasons:

• You said that 3-D Secure cards requires to perform a transaction
• Not every bank would accept voiding a preauthorization, according to http://en.wikipedia.org/wiki/Authorization_hold#Voided_transactions

Regarding the syntax validation, I'm more interested in real data validation, not just the syntax. The reason is that we'd like to have a checkout process with the least resistance possible, as in the Apple Store, where your credit card data is securely stored on a remote server and you only need to press Purchase and then enter your user password to confirm the purchase. That's the workflow we are aiming for.

Hi Alejandro,

We are wanting to do basically the same as you. Someone stores their credit card details and then we can bill them random amounts at a later date.

How did you go about implementing this in the end? Is the PreAuth with a small amount the way to go?

Unfortunately we just found out the hard way, as transactions have started to fail because the amount we passed over for the Bridge and the first transaction are different. I just assumed that once a payment object was created we could bill it for any amount, clearly this is the case after the first transaction.

Thanks

Adam