It was my impression that this past year went quite well with respect
to payment processing for EuroPython.
This is the first I have heard about problems for EuroPython 2008
(which from people I have talked to worked fantastic).
-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
