Pending from incomplete transaction - ideas?

[tmccartney]

Folks:

I have a few events running with payment through Paypal Website Payments Standard.  Frequently users have issues with Paypal - they don't understand the interface, they can't competently enter CC info, they ignore my warnings that there is no "pay later" option and that they must pay online if they're going to register online, etc.

That leaves us with a number of "pending from incomplete transaction" registrations.  Since we don't allow duplicate e-mails, the registrant is unable to just start over until we delete their previous incomplete registration.

So my questions:

1)  Is there a configuration to have an incomplete transaction be purged on its own after a certain timeout period?
2)  If not, is there a way for a user to pick up where he or she left off, assuming the user is a guest and not a registered user of the web site?
3)  Is there a better way to deal with incomplete transactions than what we're doing?

Thanks,

Tracey

[Donald Lobo]

1. no

2. by default if a payment is not completed, the participant is not recorded as attending and hence can register again. not sure why u have to delete their prior registration (we run it this way on civicrm.org)

3. at the moment no, but would be great to delete the "pending" payments after a certain time of inactivity. so a contribution or sponsorship to do so would be great

lobo

[Eileen]

How complex would it be to make it so that if someone went into an event for which they already had a pending registration (logged on users only probably) it would pick up the existing pending registration details and allow them to edit / complete it.

We often get 2-4 registrations by one person for one event because they have tried & failed (I recently realised that one reason is because we don't take AMEX but they don't realise that prior to being redirected to the payment page so they come back later with visa & try again). Also, we get pay later people come back & pay by visa.

I wouldn't want these to be automatically purged.

[Donald Lobo]

1. u'd only want to retain one of the registrations, not the others, right?

2. i dont think its too hard to allow logged in users to try to "complete" the payment (or send a reminder to non logged in users along with the checksum). if i had to estimate 20-30 hours work or so

lobo

[Eileen]

Actually I realise it's quite close to being there.  It looks to me that from the work done in

http://issues.civicrm.org/jira/browse/CRM-4320

IF a person hits registration.php with a participantID stored in the form session value they will be able to proceed with it.

//CRM-4320
        $this->_participantId = CRM_Utils_Request::retrieve( 'participantId', 'Positive', $this );
 
Unfortunately the upgrade to 3.1.2 has broken my e-mails coming out of Civi so I can't test the checksum URLs generated by waitlists etc.

[Eileen]

OK, so, I sorted the mail thing.

AND what I found out is that the functionality I need is already there & it works really well.

If you send the (logged in) user (or logged out with a checksum) to

civicrm/event/confirm?reset=1&participantId=1510

then they CAN complete the existing registration.

All that is required is a bit of code so that logged in users will be re-directed to this URL if they try the main registration URL and they already have a pending registration. (This is also applicable & useful for people who have been approved but didn't click on the URL in their e-mail)

Perhaps it could go around line 1194 in CRM_Event_Registration_Register::checkRegistration

ie. add something like this after the check for 'is_counted' types:

            $statusTypes =  CRM_Event_PseudoConstant::participantStatus( null, "class = 'Pending'" );
                while ( $participant->fetch( ) ) {
                if ( array_key_exists ( $participant->status_id, $statusTypes ) ) {
                 
                        $url = CRM_Utils_System::url( 'civicrm/event/confirm',
                                                      "reset=1&participantId==$participant->id" );
                        CRM_Utils_System::redirect( $url );
                 
        }

[Eileen]

Of course that didn't work!

[Donald Lobo]

can u elaborate on what did not work?

i suspect we can and will reuse a large section of the waitlist code for this purpose

lobo

[Eileen]

Te function

Code: [Select]

checkRegistration currently checks if the participant has an existing regisitration and if that registration matches one of the status types in :

         

Code: [Select]

  $statusTypes = CRM_Event_PseudoConstant::participantStatus( null, "is_counted = 1" ); they are redirected back to the info page.

I figured that in the           

Code: [Select]

while ( $participant->fetch( ) ) loop
I could add a second check for the status being in a second array:


           

Code: [Select]

$pendingTypes =  CRM_Event_PseudoConstant::participantStatus( null, "class = 'Pending'" );
and redirect them to the confirm url

Code: [Select]

  $url = CRM_Utils_System::url( 'civicrm/event/confirm',
                                                      "reset=1&participantId==$participant->id" );
but it didn't fire. I thought it might have been because of

Code: [Select]

        if( ! $isAdditional ) {
            $contactID = $session->get( 'userID' );
        }
so I turned multiple participants off for the event (although I'm a bit confused about why it wouldn't check in that case since I didn't think Civi could cope with registering other participants but not the logged in user)

So, it seems that my pending reg may not have been found here:

Code: [Select]


        if ( $contactID ) {
            require_once 'CRM/Event/BAO/Participant.php';
            $participant =& new CRM_Event_BAO_Participant();
            $participant->contact_id = $contactID;
            $participant->event_id   = $self->_values['event']['id'];
            $participant->role_id    = $self->_values['event']['default_role_id'];
            $participant->is_test    = 0;

            $participant->find( );
But i haven't had a chance to figure out if that's what is happening.

[tmccartney]

I guess one way around this is to somehow get into the Paypal payment screen without being sent there from CiviCRM.  If you could do that, you could take the payment and then just go in and change the pending registrants' status to "registered."  Not sure whether that's possible, though.

EDIT:  It doesn't appear to be possible to make the payment via Paypal without being sent there from the Civi transaction.  So much for that idea.

[Donald Lobo]

one potentially easy way around, is to make sure that

"pending from incomplete status" has the "not counted" status

that way folks with incomplete status can re-register and try paying again

lobo

[Eileen]

Hi Tim,

We have it set up as Lobo describes and this is currently our biggest pain-point with CiviCRM so I will have another look at trying to make that code fix work when I can find time.

We generally have to manually cancel or delete about 10% of our event registrations - the failure rate isn't that high but people who do fail generally try & try & try  (maybe with a bunch of different credit cards - or re-entering the same one a couple of times) so they create LOTS of duff registrations.

I have recently realised one reason is that we don't accept AMEX cards so am trying to make this clear through text on our site.

Eileen

[Eileen]

Hi Tim,

We use PaymentExpress not Paypal but I have just implemented a fix whereby when someone fails with a payment express transaction they get redirected back to the confirm/cancel your registration page (with a message about the transaction failing) rather than the start again page. (the confirm/cancel page is the page available from the contact's dashboard).

http://issues.civicrm.org/jira/browse/CRM-6060

This should improve it for users and prevent all the pending participation records but the pending contribution records remain & I don't think that's worth addressing until the 3.2. code is out with the code changes regarding payments