Attendee registration - PagSeguro

[flavianmissi]

This includes:

• payment by PagSeguro

If possible, create a signal so the Attendee model "payment" is updated.

[aoqfonseca]

Is not better use paypall ?

[andrewsmedina]

I'm +1 for pagseguro.

Both have an api and rates with similar values. But pagseguro have more payments methods.

[tatiana]

I find both of them important. First we implement PagSeguro, because it allows different alternatives than credit-card ("boleto", etc) and last PayPal, that is known by foreign attendees: https://github.com/PythonBrasil8/pythonbrasil8/issues/21

[fernandogrd]

There is also Moip, it's usage is growing in Brazil.

My 2 cents about Pagseguro api, expect problems. There are two api.

The 'old', which uses plain post data. Between user and pagseguro, and between application and pagseguro, the last one to receive data from pagseguro and to validate this data to be sure it comes from pagseguro. The problems I had with this API:

• No test environment for development.
• Validation server goes offline often.
• Data comes in latin-1, with such strings: 'Em Análise', so it need to be treated.
• Returns values not always respect what is in documentation. Eg: I had problems with length of fields larger than it is in docs.

There is this app from Fábio Cerqueira that handles the 'old' api and some of it's problem: https://github.com/fabiocerqueira/django-pagseguro I like the implementation, but I don't know how much it was tested in production.

The new api is a webservice, which returns data in XML. I suppose it has better quality, since is the new api. It was recently discussed at pythonbrasil mailing list: http://groups.google.com/group/python-brasil/browse_thread/thread/3ab91995d8733083

[henriquebastos]

I'm working on that with @berinhard and @aoqfonseca.

Based on our previous experiences we're aligning the subscription workflow with the Pagseguro data requirements.

You can follow up on my branch feature/registration.

[andrewsmedina]

@henriquebastos I think that pagseguro payment method, subscription workflow and attendee profile (https://github.com/PythonBrasil8/pythonbrasil8/issues/26) are three different issues.

Subscription workflow is a big issue. And these three issues and other issues are contained in this big issue. I'm working on registration workflow and dashboard for attendees and sponsors that is part of subscription workflow too.

Are you working in that feature related with subscription workflow? I recommend that the features are done in small pieces. This facilitates the merge, revision, and the teamwork.

Already exists a django app with this name (registration). And we are using this app for create attendee account. :(

Thanks for contribute with us.

[henriquebastos]

@andrewsmedina I agree on the 3 issues vision.

I'm interested in solving the [payment issue]() and for that I need a minimum subscription workflow. I won't tackle account creation. Actually it would be interesting to understand the whole expected workflow. I can easily see 2 main options:

1) Subscription -> Payment -> Account/Profile

2) Account/Profile -> Subscription -> Payment

I prefer the 1st option. Since the problem with conferences is tied to attendance confirmation, which requires payment, I'm in favor of making this step as simple and direct as possible. After the payment, we could do all sort of interactions with the attendees.

Anyway, I'll try to keep the subscription code small to enable a simple integration.

Regards the use of the name registration for the subscription app, I also found it odd. :-) However I tried to follow the current project decisions as far as I could get it and both the site and the mittun project were using the name pre-registration. I'll rename the app to subscription.

[henriquebastos]

FYI I've renamed the app and changed the branch to feature/subscription.

[andrewsmedina]

About the subscription workflow @tatiana and I had decided somethings similar to the second option you mentioned:

Account/Profile (website) => Attendee subscription (conference) (=> Payment)

Account/Profile

It's a simple user registration workflow to be used by attendees and sponsors. It includes the creation of a dashboard for these people managing their account.

Issues #26 and #31 are related to this.

Attendee subscription

It allows attendees to register for the conference or to select tutorials. After the user chooses the services he is interested, he will be able to pay them. This will create the transaction bellow.

Issue #32 is related to this.

Payment Transaction

This will be generated internally, when the user selects to pay for his subscription(s). The payment transaction will retrieve user type and what he/she has subscribed to, and payment alternatives (PayPal and PagSeguro).

Issues #11 and #21 are related to this.

[andrewsmedina]

@henriquebastos are you working in this issue yet?

[henriquebastos]

I've been traveling a lot and don't think I'll be able to finish this before May 29th. :(

[andrewsmedina]

No problem. I'm working on it

[fsouza]

Deployed.