2008/8/4 Douglas Napoleone <[EMAIL PROTECTED]>: > It was my impression that this past year went quite well with respect > to payment processing for EuroPython.
In general, it did. See my earlier reply to Paul, the problems were with: 1. Credit card payments from the old Easter-bloc countries. 2. As a consequence, we had a number of cash payments and bank transfers, both of which create a lot of work for the organisers. A particular problem was bank transfers for multiple registrations, where (if the payer quoted the registration references at all) the banking system truncated the narrative so you had a payment but didn't know what it covered. > This is the first I have heard about problems for EuroPython 2008 > (which from people I have talked to worked fantastic). As I was doing a lot of the work, I can't judge. John -- > -Doug > > > On Mon, Aug 4, 2008 at 3:23 PM, Paul Boddie <[EMAIL PROTECTED]> wrote: >> Hello, >> >> Having read some of the discussion on payment providers, which has been >> something of an issue for EuroPython for the past two years (at least, but >> with more urgency this year and last), and noting that PyCon US isn't >> experiencing much better, perhaps we should seize the opportunity and set >> down what we want, what we don't want, and what we can live with. >> >> Here are a few things which I think have come out of the discussion so far: >> >> Reliability - PayPal seems pretty awful with respect to reliability and >> actually recovering from errors, and perhaps something >> better that handles credit/debit card payments might be >> worth investing in >> >> Integration - having the ability to find out who paid is obviously >> important, along with knowing whose payments haven't worked >> for whatever reason; I remember looking into some payment >> provider API back in the days of Indico and getting their >> payment modules working with an account that I think had >> expired, but simplicity and security are the key factors >> here; to be able to conveniently reconcile registrations >> with payments would reduce the organisers' workload >> >> Convenience - for the end-user, I think John's solution is pretty good in >> that the payment interface is handled for us, and it's not >> like the Reval payment system where you get bounced off to >> an iframe served out of Estonia ;-) (but we still rely on >> PayPal, currently) >> >> Versatility - being able to deal with major cards, and PayPal for those >> who absolutely must use it, is essential, whereas bank >> transfers are most likely to get reconciled by other means, >> I imagine; handling the EuroPython "absence of VAT" >> requirements is a necessity >> >> Maintenance - if such things are going to cost money, and need to be active >> (because financial institutions love to declare things >> dormant and ask for more money to "reactivate" them), then >> perhaps we need to consider an arrangement where more than >> one conference can use the provider, although this may well >> complicate the administrative arrangements >> >> Does this (minus my opinions, of course) sum up the situation? The stuff >> about >> a common provider arrangement is probably unfeasible, given the need to have >> money going into different accounts, having different legal entities of >> different kinds in different countries, but then again, perhaps the PSF >> should be aspiring to lowering the barrier to entry for Python conference >> organisers. >> >> Paul >> _______________________________________________ >> Europython-improve mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/europython-improve >> > _______________________________________________ > Europython-improve mailing list > [email protected] > http://mail.python.org/mailman/listinfo/europython-improve > _______________________________________________ Europython-improve mailing list [email protected] http://mail.python.org/mailman/listinfo/europython-improve
