6

I've been evaluating a credit card processing system and I'm trying to decide between the two options provided for processing payments

Option one is

  1. Include a Javascript library on the VF page
  2. Capture the sensitive data in regular HTML Input fields (i.e. no binding to Apex controller)
  3. Use a function in JS Library to get a token for that data from provider via HTTPS
  4. Pass token to the Apex Controller and make callout to a REST API to charge the card.

This is the flow they recommend, primarily I think because it avoids any sensitive data ever being passed to the server on the requester side.

The second option is to capture all the data in regular inputFields bound to the Controller, and charge the card via a HTTPS callout to the provider's REST API that would include info like the CC number

I can see why the first is more secure - no sensitive data in the logs etc, but should that be a big concern if the back end is Salesforce? I've never liked relying on javascript on my pages for things like payments because it always seem easier for users to break it when they create a new VF page.

Wondering if other folks have approached the same problem, and what else I should be considering?

2

I don't see a major issue with using an Apex class to back the Visualforce page and sending the card details to it via inputFields. The data is still being passed over SSL.

If you do go the full Apex route, make sure you use the transient keyword on the variables that contain sensitive information. This will prevent them being passed around in view state.

Does that Javascript option send the transaction amount along with the card details? I remember seeing an exploit where users could modify the charge amount via Javascript and pay only a few cents. For this reason I prefer to do CC processing server side where it would be harder for them to tamper with the amounts etc...

  • It doesn't send the amount - that's sent vai the REST API call. Re Transient, don't they need to be in the viewstate if I want to use them in my Controller for a callout? – BritishBoyinDC Jul 2 '13 at 16:59
  • The transient values will be returned to the controller when the user does a post back to the server, so you can use them for the callout. They won't return to the browser in view state. – Daniel Ballinger Jul 2 '13 at 19:32
1

I would recommend the apex route with a controller rather than the javascript route for the following reasons.

  • Handling javascript postbacks from the payment gateway on declines adds complexity to your code which would cause debugging issues like invalid credit card numbers, etc

  • If your payment gateway does a post back with a succesful transaction, you would need to handle another asynchronous call which could be a problem.

If you use apex, i would still recommend the following

  • do the callout in the controller and handle declined messages with a form load with prepopulated payment information.
  • Create an apex class to store the payment information temporarily for the form submit.
  • Once the transaction is complete, clear out all the variables on the apex class.
  • Re "Create an apex class to store the payment information temporarily for the form submit." - that makes sense. What I am concerned about though is that the cc information is available in debug logs. Any way I can prevent that data every being visible to a SF user, but still use in a callout to the service? – BritishBoyinDC Jul 2 '13 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.