I am working on a registration form for an event. The user is supposed to pay $50.00 to attend. I am trying to work out how to handle the case where the user cancels the paypal transaction. As far as I can tell, the results are stored into the database regardless if the transaction was successful. Therefore, I have no way to know if they actually paid or not.

Is there a way to get a form to store whether payment was successful or not?  Am I missing something from the examples?

Kevin

Kevin,

Are you using PayPal or Authorize.net to process payments?  In both scenarios, you can set up completion events that notify you once payment is completed.  You can either set up an email that goes to you (or just add yourself as a bcc in the confirmation email).  You can also set up an SQL event to  update a table for you. 

With Auth.net, it will be more immediate.  However with PayPal, there may be a delay if your customer just set up a PayPal account & is still going through verification, etc.  So your events will not fire until your form gets the notice from PayPal (or Auth.net) that payment is completed.  

Additionally, these payment gateways will provide other means of payment confirmation.  PayPal should send you an email also regarding your transactions.  I believe you can access your transaction reports if you log into your Auth.net account.

Candace

Kevin,

Hi. Thanks for your feedback. Please understand that during design we had to really look at many implementation requirements, purchase types (subscription VS standard purchase), and feature requests. Our development went along with design and although there might be some confusing parts, this is really the best solution to meet as many PayPal implementations as we reviewed. If you simply wanted to accept payments from PayPal, you wouldn't event really need to use the gateway at all (you could just redirect them to PayPal with the appropriate details), what if a user canceled their subscription... You probably want them to also have their role removed right? What if their payment failed, do you want them to be notified? What if their payment for purchase or subscription was made from an ECheck and therefore was 'Pending' and not 'Completed'. What about other subscription types such as initially free, or maybe a trial period for two weeks and then free, or what if you want the user to optionally change the gateway from PayPal to Authorizenet and accept credit cards? What if you wanted to redirect them to different pages after their purchase if they purchased 'Product A' VS 'Product B'. I guess I am just trying to make the point that although your implementation is a very common one, there are many what-if's that go along with it and that the module can handle. So lets get to the basics.

First, a few helpful resources....

1. On Beta Springs there are several examples of users implementations they setup and we either assisted or handled the implementation on there so they could reference for their own site. This might include subscriptions, standard purchases, or other basic scenarios such as yours.

2. Within the Dynamic Forms demonstrations (several now) we have a step by step walk-thru of many different working implementations which should include an IPORTABLE file you can download to have the same implementation and see how it works or have a direct copy of it.

3. We are also working on some troubleshooting guides which will assist seperate from Beta Springs and the tutorials/demonstrations on Dynamic Forms. We should have these completed soon and will post links to these in the forums and a newsletter.

Next... A few quick tips and things to keep in mind.

1. The Dynamic Forms module needs to be on a page that is visible to all users, this means that both the page and module needs to be visible to all users. Why? When the user completes the payment, or if any PayPal Instant Payment Notifications come into Dynamic Forms, PayPal needs to be able to talk to the form. So... If a user cancels their subscription 6 months from now, you will want to remove them from their security role, or maybe if an ECheck payment goes from pending to completed 3 days after the purchase you want to finally send out the confirmation email to them that their order is ready etc... In order for this to happen PayPal has to 'talk' to Dynamic Forms and the only way it can do this is if the module is present on a page that is visible to all users. This allows for a 'live' communication between PayPal and your Dynamic Forms module instance.

2. The best suggestion I can have for any PayPal implementation is to make sure to setup a PayPal Sandbox account (I cannot stress this enough), you will want to make sure you have your form and all completion events working with many tests before you enable it in production. Its not that you need to be a PayPal Certified Developer or anything, it just helps to get a better understanding of their different areas of PayPal IPN and Dynamic Forms.

3. If you Enable Debug Mode, you will be able to submit the form and see the information that is being sent to PayPal. In any type of support issue (including this thread) mentioning the specifics of where in the process your are having problems will help. For example, is it redirect to PayPal and accepting Payment? If its getting this far then where does it redirect the user after payment? etc... This will help us with the support issue and knowing where you might be running into problems.

4. Assuming PayPal is accepting payments and processing them successfully... and assuming that the module is visible to all users so that PayPal can talk to it.... You can go to Admin, Event Viewer, and then within there you can visit the Event Viewer Settings. Make sure to turn on 'All' for 'Debug Info'. If this is enabled it will log several events for each PayPal IPN response that comes in from PayPal. This can help in finding out 'is the right Instant Payment Notification coming in', and 'is it doing what its supposed to do once it comes in'. Maybe you think the payment is completed but its really on hold from PayPal, or maybe they paid from ECheck and its pending and didn't come in as completed? Either way, this area will help you identify what is coming in from PayPal when its attempting to talk to Dynamic Forms.

5. Dynamic Forms (with and without PayPal) processes all completion events after form submission. This includes redirecting the user to different pages based on form submission (otherwise you can set this setting under general configuration where the user goes), email events, adding the user or removing the user from a security role, processing a silent HTTP Post, and also processing any custom SQL statement. Many of these completion events are advanced events that we don't recommend for all users or implementations, however they are available if and when necessary. These completion events can be fired off for any field response or they can be fired off based conditionally upon a users response. For example, maybe you want to add the user to the role 'Employer' if they choose that option from a dropdownlist or maybe you want to add the user to 'Job Seeker' if they check or select that option from one of the fields. So... understanding completion events, this now sets us up for PayPal integration. The way the PayPal integration works is that it 'links' each PayPal IPN response to a completion event. What this means is that you can setup the 'Pending' IPN response from PayPal to be tied to a pending email, and also the 'Completed' payment response be tied to a 'Completed' email. You might tie many other events to subscriptions such as Payment Failed, Subscription Canceled, Subscription End of Terms, etc... For each PayPal IPN you want to fire the event, you can select the event you setup from the dropdownlist within the payment gateway and which IPN responses you want that event to fire for.

6. There are at least two completion events that need to be setup and linked to PayPal. This is for cancel redirect URL and success URL. These events are linked to the PayPal responses for success redirect and cancel redirect, and the module uses these whenever the user goes to PayPal but then cancels the payment, or after successful payment it knows where to send them. Keep in mind that a successful payment doesn't mean that its completed, just that they are finished with the process (such as ECheck when its pending)

The last thing ill mention is that there are a few known issues with implementations (we have probably implemented or assisted implementation now on about 40+ implementations) and that is to watch out for spaces in the additional parameters area. We are checking this ourselves for future releases to automatically remove spaces within the parameters.

Hopefully you will find these suggestions and tips useful, what we really need to know to help you out is specifically where you getting held up in the process, and other relevant information that you can find from enabling the Debug Mode and also from checking the Admin, Event Viewer area. Typically these two areas will provide as much information from our support staff that should be able to help. Additional requirements, possibly your parameters, and other information will be helpful to us as well.

Thanks for your patience and I am confident once you are up and running you will be a happy camper. I will also follow up on this thread to post other implementations on Beta Springs, Tutorials, and several other forum threads related to PayPal implementations.

Ok... This thread was longer than I originally thought it was going to be


-Chad

Works for me. Do you have a suggestion as to one that is known to work? There are many up there, but since Betasprings is often used for troubleshooting, customer support, and bug reporting, I have no idea which ones are 'valid' vs testcases.

Chad,

I have made an attempt at doing a flat SQL file using the examples you have on the web. No luck as of yet.

http://www.betasprings.com/Dynamic-...px is the form I have been working on.

I went ahead and created a flat database FLLRegistrations2008 on the betasprings server. I am using slightly modified SQL scripts (trying not to save the horizontal rule questions). Credit Card/Purchase order is the EnablePGateway flag as discussed in one of your tutorials.

When the gateway is turned off (purchase order/check on the form) and debug mode turned on, I see that all of my completion events fire (including the Gateway linked events). I didn't want that to happen.  Could use some help here. How do I prevent all of the completion events from firing? Specifically, I have SQL completion events for each callback from PayPal. I also have a completion event for sending confirmation email on the Completed paypal event. If the gateway is disabled, ALL of the events fire.

The Insert script doesn't appear to work. I am not enough of an SQL expert to know why. It looks good to me. Net result of all of this is nothing in the database. On my live system, the confirmation emails (both of them) get sent with appropriate data in them.  

With the gateway turned on, check out the seperator characters in the URL 'Default.aspx¬ify_url=http://'

I was expecting to see an & but perhaps not? Another funky character just before cy_code in the URL

Progress so far:

I have managed to fix the SQL scripts (needed quotes around the IP address and userID fields. Your example canned scripts don't function, needs fixing. I also replaced $(DSParam1) in the scripts with '$(UniqueCompletionID)'. So I have data in my database.

Issues at the moment:

I have no way to create the database record before calling out to PayPal. In my PayPal gateway completion events, I need a 'Completion Event before calling PayPal' sort of functionality so I can call my SavetoDB SQL script.  That way, if PayPal calls back, I have a record to get updated.

In the case where EnablePGateway is FALSE, all of the events are firing. I will monkey about with this to see if I can get it to work. I will update the script on betasprings in a half hour or so.

Kevin

Kevin,

Hi. A few thoughts and comments on this...

1. Yes, we identified the issue with the generated SQL Scripts and the IPAddress parameter. We have this fixed for the upcoming patch of 2.7.2 which includes this and some other minor fixes.

2. It is my understanding that the SQL Events should still have access to all necessary fields used during the form, the best way to tell this is to use all parameters (or literally copy and paste) your SQL statement into an email event. This should show you exactly what SQL query is getting generated. Maybe all of the fields are there except for the unique completionID?

3. Another option is to use a SQL event linked to PayPal IPN and just update a specific hidden field on the form. For example, lets say you had a hidden field called 'Paid' you could initially set it to false, then have a SQL event that (based on the unique completion ID) would update that record in the DynamicForms_QuestionResponse table and set 'Paid' to be True? If this works for you let me know and ill generate the SQL you would need for the event.

Unfortunatly right now all completion events have to be linked to a PayPal IPN response code and cannot be fired BEFORE the PayPal response, so we might need to review the query you are using and since its working without PayPal determine if its A. getting fired from the PayPal IPN or B. getting fired by one of the tokens or parameters is not valid and not getting replaced within the query. We can find out A if you use a static query (instead of the tokens just use an actual text) and we should also be able to look in the event viewer to determine if its firing. If we find out its firing but not replacing a specific token (all tokens should be available) then we might have to put the query in an email event to determine which token is not getting replaced properly for the query.


-Chad

Yeah... The notify URL shouldn't be doing that. Was this a temporary issue that came up or is this still happening? If the notify URL is being set improperly it might be the reason the PayPal IPN responses are not coming in.

-Chad

As for the bad URL, This happens every time. Happens on my dev system, production system, and betasprings.  Must be a bug somewhere.

You can also review this thread... I think this covers the same thing I was explaining related to the Pending Status if you have the Payment Review Enabled.

So, I have had to give up on the flat table version, I am running out of time. I am going to try changing the value in the response table, which is an enormous kludge.

The PayPal gateway function in DF is, well, just broken. Sorry guys. This needs to get addressed. I have nearly 35 hours into this single form, and still have nothing working yet. I am not asking for the moon and the sky to be able to know on my spreadsheet that the payment happened succesfully.

The straight forward answer would be to have the ability to run a completion SQL event BEFORE sending things to PayPal. The key problem is not having a unique completion ID and data in my flat database before calling out to PayPal.

This should be simple simple simple! At the moment, it is definitely everything but.

Kevin

First, let me say your product support is great. I appreciate very much the effort you are putting into this.

However, the steps to do the very simple task of getting a record that a payment succeeds with PayPal are very painful. Either that or the documentation needs a whole lot of help. Well, ok, both really.

The events are firing, but managing the data is the issue. There are two forks to this, which both end up with the conclusion that this isn't ready for primetime.

Here is the simple problem I want to solve. Please attempt this yourself from scratch and you will see a) how difficult and obscure it is b) that samples and documentation don't exist for this. Don't skip any steps! The devil is in the details here.

Have a simple form that collects information from 1500 registrants, then allows them to pay with PayPal. That means manually processing emails isn't a viable option. Using the forms package, be able to generate a spreadsheet or report table of who has paid and who has not. Easy? Well, not really.

Fork 1: Try using a custom SQL script and a flat table and a report table. The issue is that when a PayPal gateway is enabled, the call out to PayPal occurs before any completion events, meaning that my form can't save data to the custom flat table. Specifically, I can't execute SQL commands before the call to PayPal. This is an issue because when PayPal calls back with its notification, the form data is not in the table, therefore the completion event that is tied to the PayPal action has no record to update. Hence, I miss the update of the flat table. Therefore, this route doesn't work. I made an attempt at a two part form, but now have usability issues. If the user hits the back button, a new record is created with a different UniqueCompletionID, plus a host of other potential ways for it to fail.

Fork 2: Try using PayPal notifications to update the response in the DynamicForms_QuestionResponse table. I had to wade through two tables using SQL commands in DNN to find the unique question ID, which meant finding it in the DynamicForms_Question table. Now I have a form that is functioning, but to copy it and use it again will require me to go find new GUID's. I find this to be a kludge. I am actually a pretty smart guy (I have a degree in computer science and 20 years of experience writing operating systems). I was able to figure this out, even though what I really wanted to do is be a forms package user who didn't have to grovel through database tables to do something so simple.

So, for all intents and purposes, DF is broken here. By broken, I mean in one case there isn't a reliable way to implement a straight forward simple form using the PayPal feature. In the other case, it is possible, but what good is a nice GUI drag/drop interface when I still have to grovel around database tables using tools outside of DF to find GUIDS that are now hard coded into my form.

Now, I concede that I am certainly not an expert at Dynamic Forms. Perhaps there was a simple example of a form that uses paypal to keep track of who has and has not paid. I sure couldn't see a way to do it using the given user interface. My bet is that the MANY users you are quoting are just assuming the payment worked, are manually processing PayPal emails, or have had to go through the same kludge I did. I honestly would welcome an example of how this works well. I have looked and asked for exactly that over the last week.

Please consider this very constructive feedback. That is my intent. I actually think this is a fine forms product that needs some tweaking to make it better.

Kevin

Kevin,

Hi. I just wanted to follow up on this thread. We are adding a few quick enhancements that will be part of an incremental enhancements build of 2.7 (should be released as 2.7.4 within the coming weeks). The enhancements will include a few minor enhancements (we will issue a full announcement/forum thread with the list) but directly related to this you shoudl have the ability to choose a field which will have the last PayPal IPN status code and also the ability to fire off completion events before the user is ever redirected to PayPal. Here is a screenshot of what this looks like in the back-end. We have also added a sort order field for completion events.

-Chad