JustGiving SDIs, ExitUrl redirection and monthly direct debit donations. Y U NO WORK?!

When we first implemented SDI, it worked for everything everywhere. At that time, we accepted single donations via credit card and PayPal, and monthly donations via a recurring credit card mandate where we manually re-requested authorisation on a schedule until the end user stopped it from their control panel. Nice and easy.

SDI operates on a single principle: If you specify an ExitUrl, we guarantee that if the user completes the donation flow, regardless of the success of the donation, you’ll end up with that user hitting the exit Url. This allows people to integrate, validating the donation result using the API, and keeping the user on their website for anything they want to message after. It also hooks in to a few iPhone and Android apps, where that ExitUrl re-launches the application through some nifty JavaScript hacks.

Several months later, we implemented what we internally call “IPDD”, internet paperless direct debit. Which is… kind of cool? Depending on what you think about the awesomeness of lack thereof, of Direct Debits. Suffice to say, charities were begging for it, because recurring donations are really good for them (largely because people forget to ever cancel them, and they’re a solid source of predictable income for financial planning). We switched out our credit card mandate for direct debit processing.

Part of the legal requirements surrounding Direct Debits is that you have to show some *very* specific information in a *very* specific format when the user creates one. Basically, the user needs to know their rights, they need to know how to cancel, and these things are all the more important when you’re just pulling money right out of their account, as a result, we were literally forced to show the success page that you’ll have seen if you’ve set up an IPDD on JustGiving. It’s not pretty, but in short, there’s a reason that all direct debit forms look the same.

Jumping back to SDI, the way we ensure that a user is correctly redirected, is that we don’t give them a choice, this is also the reason that the users don’t see the “leave a message” page during SDI, and that we implemented a default message in the SDI url schema. We hook on to our processing page and immediately send them back to the integrator after we have some kind of response (or send them regardless after 13 seconds). Unfortunately, our direct debit confirmation page comes *after* the processing page (because by definition, it comes after the “donate” click) in the process.

So, long story short: we’re required to show a direct debit confirmation, and SDI needs to hook in before that point and as a result, SDI broke for direct donations when we integrated IPDD and we had to make the choice to leave it broken. Furthermore, the nature of the IPDD produce means that (I believe) we are legally required to supply the user with certain information.

So, rock and a hard place right?

Honestly, at the moment this hasn’t been the most high priority thing to look at, as it’s not a huge use case (this is also why I’m writing this on a Sunday afternoon) but I feel like we need to do *something* about it, but my options are fairly limited.

Here are a few ideas that have been suggested internally and externally with some pros and cons.

· Do a server side call to the return Url to confirm a donation

o Pro: You’ll still be aware of a donation and can sync your data
o Con: Not the anticipated user flow, this kind of various will confuse integrators
o Con: Useless for UI based logic at integrators end

· Move the direct debit “confirmation” information to before the “confirm” button click

o Pro: Almost a perfect solution, as we could then re-enable SDI
o Con: Technically wouldn’t be a “confirmation” page, so may have to get some special sign off from external parties

· Don’t show the confirmation at all, just send the user an email

o Pro: Again, ideal from an integration perspective, may lead to some users to be confused and not realise it’s actually been “done”, so may lead to support issues
o Con: Not even sure if we’re allowed to do this. Would definitely need external sign off

Does any have any other ideas about how they’d prefer this to work? Regardless, I hope this answers some questions related to this problem.

For my part, I’d love to fix it, but it’s not super high priority right now. HOWEVER, if there’s something we can do practically with a small amount of effort, and the demand is there, I’m sure we’ll get it looked at much sooner.

(Cross posted to Google groups and my blog for seachability)