views:

66

answers:

1

Hello all,

I am in the process of writing the final stages of a checkout module using the FirstData Global Gateway API for a client. All the form views for data entry have been created and the controllers are successfully communicating test data with the FirstData webservice.

I am looking for thoughts on best practices on how to structure the user experience for checkout after the 'process order' button is clicked.

I am planning on using javascript to disable the process button after it is clicked and have the information passed to the Web Service during this delay. What are some methods you may have used in the past to create this delay while informing the user that the payment call is being made. What are some methods you may have used in the past to best operate the callback function that notifies if the transaction has been approved or declined? Has anyone found processing all this information in the same script using PHP_SELF for the action, or is it generally better to place this logic elsewhere?

Just some general inquires to help guide the process through a little trial and error. Maybe the response will help collect some pretty good thoughts for everyone's use.

+2  A: 

What are some methods you may have used in the past to create this delay while informing the user that the payment call is being made?

You don't want to delay the process any as processing the payment will incur enough overhead for natural delay to occur by itself. Your goal at this point to prevent duplicate submissions and let the user know something is happening while they wait. Disabling the submit button is a good idea. Also, creating a unique key for that checkout process that also needs to be submitted with the order is a good idea. When they submit their payment you check for that key and make sure it is there (usually it is in a session variable). If it is delete it and then process the transaction, if they submit the form again it will then be able to be flagged as a duplicate transaction.

What are some methods you may have used in the past to best operate the callback function that notifies if the transaction has been approved or declined?

The payment gateway is going to return an approved, declined, or error value. Nothing fancy so there's really no fancy handling required. Approved transaction should have all relevant order and database information actions performed and then the user should be taken to a thank you/receipt page. Errors and declines can be handled in a similar ways with the user being presented with the checkout page again. If the card is declined let the user know politely that their bank declined the transaction and invite them to use a different credit card. If there is a processing error you can either ask them to try again or direct them to contact you by telephone to place their order.

Has anyone found processing all this information in the same script using PHP_SELF for the action, or is it generally better to place this logic elsewhere?

Tomato, tomáto. It all depends on your programming style. Having the payment process on the same page as the form is fine. I've done it. All that matters is that the payment is handled properly and the user sees what they need to see. What happens in the background doesn't matter to them.

John Conde